• Agile Community
  • Agile For All
    • Agile for All Home
    • What We Do
    • Upcoming Courses
    • Contact Us
  • Blog
    • All Blog Posts
    • Agile Resources
    • Homeschool Resources
    • VC Interviews
  • Forums
    • Watercooler
    • Agile Topics
    • Agile Videos
    • Job Postings
    • Pre-Work & Documents for Training
    • Webinars & Live Stream Replays
    Sign in Sign up (it's free!)
    • Agile Community
    • Agile For All
      • Agile for All Home
      • What We Do
      • Upcoming Courses
      • Contact Us
    • Blog
      • All Blog Posts
      • Agile Resources
      • Homeschool Resources
      • VC Interviews
    • Forums
      • Watercooler
      • Agile Topics
      • Agile Videos
      • Job Postings
      • Pre-Work & Documents for Training
      • Webinars & Live Stream Replays

    • Log In
    • Register

    Category: Estimation

    Agile antipattern: Sizing or estimating bug fixes

    Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between…

    Bob Hartman 2010-05-05
    10 Comments

    Agile antipattern: Taking on large stories

    Earlier this week I posted a blog entry “Agile antipattern: Burndown charts that hide the truth” which dealt with one way a burndown chart could…

    Bob Hartman 2009-12-09
    5 Comments

    Agile antipattern: Comparing velocity between teams

    I recently saw an excellent blog post about iteration velocity.  Good reading in general, but the last paragraph really got my attention and is why…

    Bob Hartman 2009-04-30
    2 Comments

    New to agile? Do the simplest thing that works – THEN STOP!

    As an agile trainer and coach I often see new teams struggle with a simple question: “How much to do on a user story?”  A lot…

    Bob Hartman 2009-04-27
    0 Comments

    Ten Ways to Improve Your Planning Poker Results

    People who promote the use of Planning Poker understand some of the main reasons why it is successful.  People like Mike Cohn have been very instrumental…

    Bob Hartman 2009-04-02
    5 Comments

    Agile antipattern: But the development lead said it would take way less time than that

    I’d be rich if I had a nickel for every time I’ve heard this, or something very similar to it, in the past 30 years!  Alright,…

    Bob Hartman 2009-03-02
    1 Comment

    Where do you want to go?

    • Community News Feed
    • Upcoming Courses
    • Blog Posts
    • Groups

    Welcome New Members

    Profile photo of david daukas

    david daukas became a registered member 15 minutes ago

    Profile photo of Rodrigo Giraudo

    Rodrigo Giraudo became a registered member 3 days ago

    Profile photo of youssef rzaini

    youssef rzaini became a registered member 3 days ago

    Profile photo of Brian Aaland

    Brian Aaland became a registered member 6 days ago

    Profile photo of Andrew Ryder

    Andrew Ryder became a registered member a week ago

    Making Agile a Reality.®

    303.766.0917 | 4833 Front Street, B-194 | Castle Rock, CO 80104 | © 2023 - Agile For All

    • AGILE COMMUNITY
    • UPCOMING COURSES
    • WHAT WE DO
    • REQUEST A QUOTE


    Forum Description

    I'd be rich if I had a nickel for every time I've heard this, or something very similar to it, in the past 30 years!  Alright, that's taking it too far, but I think I could at least afford a really nice dinner out with my family on the amount I'd have received.  But that isn't the point.  The point is anyone thinking this statement is a valid excuse for poor results is wrong on several fronts. Before we go any further, if the title intrigued you, immediately click on the image to the left and purchase Mike Cohn's bible about agile estimating and planning!  If you don't own this book, then I now know why the title of this blog post made you look further!  Now, back to the issue at hand and why it is wrong to think this way.  First of all, this type of statement is part of the reason a waterfall model doesn't work.  In the waterfall model it is typically development leads or other managers giving the time estimates.  This isn't a written rule for a waterfall approach, but it seems to be given how often I have seen it in my career.  Let's think about it for a second and see why this is the wrong way to approach things.  Is the development lead rewarded when a lot of software gets completed?  If so, this incentive is at least subliminally causing them to cut time estimates to the bone.  Is the development lead more experienced than most members of the team?  If so (and I hope the answer is yes!), then he or she is likely to estimate for their rate of development, not the rate of development for an average team member.  Does the development lead have enough clarity to actually give a meaningful answer?  If yes, great, but in most cases the answer is no.  Again, this leads to an estimate which may be on the low side due to a lack of knowledge about specifics.  So just from a logic point of view, using a model where the development lead estimates time is bad. Second, on agile teams some goals are to collaborate well, and be held accountable for results.  If this is true (and it is), then we are completely bypassing both of these.  We are not allowing the team to collaborate to come up with an estimate they can live with.  Further we are holding them accountable to a result when they were not given the opportunity to give input.  We are back to waterfall where someone says we need x by date y and I told with Joe and he said we could do it, so do it.  That isn't agile, that's lunacy! Lastly, we have taken a single data point and assumed it is 100% accurate at the start.  Even in a waterfall project it is well known that accuracy of estimates at the beginning of a project vary widely.  Review the cone of uncertainty to learn more about how bad it can be.  Part of our goal in agile is to deal with the cone of uncertainty by iterating toward a result.  So to add insult to injury, we assumed the estimate was correct, and we didn't check on it each iteration to deal with reality.  How not agile can you get? Project managers are starting to recognize that estimating is different in agile.  This blog post from PM Toolbox is just one example.  There are many more things to consider when estimating.  For example, things sometimes get more difficult at the end of a project (or at least development slows down).  There is a reason the 80/20 rule is often cited!  There are lots of ways to estimate, and lots of ways to do it poorly. The bottom line is the worst thing anyone can do is ask a development lead to estimate something and then hold an agile team accountable to the estimate.  Collaborate and use planning poker to create estimates and you will be a lot happier in the long run.  There is even planningpoker.com for teams that are distributed!  Time for me to get ready for a trip to Boston where I'll be starting down the path of  Making Agile a Reality™ for another client.

    Report

    There was a problem reporting this post.

    Harassment or bullying behavior
    Contains mature or sensitive content
    Contains misleading or false information
    Contains abusive or derogatory content
    Contains spam, fake content or potential malware

    Block Member?

    Please confirm you want to block this member.

    You will no longer be able to:

    • See blocked member's posts
    • Mention this member in posts
    • Invite this member to groups

    Please allow a few minutes for this process to complete.

    Report

    You have already reported this .