Great Dane, Golden Retriever, Chihuahua == Developer Estimates

I just read Ayende’s and Udi’s post on estimation.  I was intrigued because over the last three year we have been using “story units” to estimate our work load for all our projects to great success.

Story Units (points, Bellware calls them fibs) are not for the faint at heart as there accuracy tends to increase as a team develops more software together.  This is due in part to the central limit theorem.

Mike Cohn says it best:

The Central Limit Theorem tells us that the sum of a number of independent samples from any distribution is approximately normally distributed.

For our purposes, this means that a team’s story-unit estimates can be skewed way towards underestimation, way towards overestimation, or distributed in any other way. But when we grab an iteration’s worth of stories from any of those distributions, the stories we grab will be normally distributed. This means that we can use the measured velocity of one iteration to predict the velocity of future iterations.

Naturally, the velocity of one iteration is not a perfect predictor. For example, an iteration containing one ten unit story rather than ten one-unit stories would be a less accurate predictor. Similarly, velocity may change as a team learns new technology, a new domain, or becomes accustomed to new team members or new ways of working.

My own personal experiences proves that this theorem is factual.  When the development team was forming, our story estimates were all over the map.  One developers 1 unit (12 ideal hours) story would turn into an 8 unit story by the time the team completed it.  Another developers 3 unit story would take 0.5 units. Over the course of each iteration our accuracy increased and the velocity became consistent.

For those of you that have never heard of story point estimating let me break it down for you. 

Agile project terms differ from process to process but they have the same basic similarities.

A basic project looks like this:

As you can see there is a basic inception phase that the project team uses to estimate the duration and cost of the project.  The product owner gives a high level scope of what the application will accomplish.  From this high level overview a vision statement is created by the entire team.  During this phase the product owner outlines the high level features of how the application will function.  Try to not confuse this with a work break down structure exercise it is similar but doesn’t go into that level of detail.  So lets say the team came up with the following list of features.

• Welcome Screen
  • Login Screen
    • Create Customer
      • Look up customer
        • Create lead
          • Admin: Create Campaign
            • etc….</ul> From these list of features the development team gets together and plays planning poker with each feature. When the team comes to a general consensus on the size of the feature, a unit value is assigned to it.

            Here is where my dog analogy comes into play.

            Lets say the first feature is valued as a Golden Retriever.  You simply look at the next feature in relation to the first and ask yourself one simple question,
            “Is it bigger or smaller than the Golden Retriever?” If it is smaller how smaller? Chihuahua or Poodle?  Well I am sure you get the picture, the point here is not about accuracy as more as it is volume.

            After you have gone through all the features you simply add the units up.

            • Welcome Screen – 1 Units
              • Login Screen – 3 Units
                • Create Customer – 8 Units
                  • Look up customer – 6 Units
                    • Create lead – 6 Units
                      • Admin: Create Campaign – 8 Units
                        • Total: 32 Units</ul> Now you have your units for all the features.  This is where I am going to diverge from traditional agile practices simply because I am in a enterprise environment and I answer to a PMO so I have to come up with a target completion date and estimated cost.  To do this I am going to have to rely on iteration velocity.

                        Within each release there are a certain number of development iterations. Most teams typical iteration length is 2 weeks, I prefer 1 week iterations as it accelerates the feedback loop. Each iteration is given a development velocity.  Velocity is a measure of how much work the team can accomplish in an iteration.  As an example lets say you have a team of 4 developers and they have been working together for sometime.  Their velocity is 8 units per week.  On the other hand lets say you have a new development team of 4 developers.  Their velocity would probably be half of the seasoned teams velocity.  It would probably (hope) take around 6 iterations by the time this new team is able to match the velocity of the seasoned team.  There is a huge theorem I use at work to predict this but I don’t want to bore you here.  The main point is velocity is not a constant it is simply a measurement of estimated performance.

                        A typical release might look like this.

                        

                        So you have the following phases in a release:

                        • Storming
                          • Planning
                            • Development Iterations A (8 Units)
                              • Development Iterations B (8 Units)
                                • SIT
                                  • UAT
                                    • Production Deployment</ul> Velocity for the release is 16 units and the release is approximately 3 weeks in duration.  So in 3 weeks you can have 16 units worth of working software ready to go into production.

                                    Lets go back to our Feature list example. You know the total count is 32 units, based on how awesome your team performs the entire projects is going to take approximately 2 releases to complete.  Because you are a seasoned project manger you plan for one additional release in reserve.  The total project estimate is 9 weeks.  From there you can figure out person hours on your own.

                                    Release Planning Estimation: Planning Poker Part Duex

                                    Great now you are into your first release but what are you going to work on. 

                                    DO NOT make the fatal mistake of using the high level estimates you did during the inception phase to plan the actual stories for the release, those where just estimates!

                                    For the sake of time lets assume that your project owner has given you a list of features they would like accomplished for this release.  What you do now is sit down with your product owner and go over each feature that has been prioritized for this release utilizing DDD modeling you break the feature into stories.  Once each story has been defined.  The developers take some time to break the story into task and estimate them at a finer of level of course using the planning poker scheme as before.

                                    Story: Blah blah blah – Original Estimate (3 units)

                                    • Task: create Blah entity  –  0.25 units
                                      • Task: create blah database table – 0.25 units
                                        • Task: create UI mapper for Blah – 2 units
                                          • Task: create web page elements for blah –  2 units
                                            • Task: create blah validation service – 0.5 units</ul> New Estimate after task analysis – 5 Units

                                            Story: foo foo foo – Original Estimate (5 units)

                                            • Task: create Foo entity  –  0.25 units
                                              • Task: create Foo database table – 0.25 units
                                                • Task: create UI mapper for Foo – 1 units
                                                  • Task: create web page elements for Foo –  1 units
                                                    • Task: create Foo validation service – 0.5 units</ul> New Estimate after task analysis – 3 Units

                                                    You do this with each story that the product owner has assigned to the release.  The product owner simply evaluates how many points they have to work with and assigns the stories until the iteration velocity budget is exhausted.

                                                    • Iteration A – Velocity 8 Units
                                                      • Story A: 1 Unit
                                                        • Story B: 2 Units
                                                          • Story C: 0.5 Units
                                                            • Story D: 5 Units</ul> </ul>  

                                                          NOTE:  It is very important to track the target vs actual of each story as I tend to see in my team that they are very accurate with 0-3.5 unit stories anything above that and there accuracy starts to diminish exponentially.  To minimize the this risk we ask the developers to determine if a 4 unit story and above is an epic and can it be broken into smaller stories? Of course we ok this with the product owner before simply breaking out even more stories.

                                                          Another important aspect is plan to the horizon.  Meaning you can plan for iteration B but understand that it will more than likely change. “Embrace Change”  Sometimes this change is for the good and sometimes not so good the point is reflect after every iteration and determine if the stories in the back log are still what you estimated them to be.  Some may have gotten smaller based on frameworks and patterns you may have introduced during iteration A.  Some may have increased because of an issue you came across in iteration A.

                                                          What I love most about Agile is you can’t hide!  It brings everything to the forefront for you to deal with now, not later but now!

                                                          I hope I haven’t confused anyone with I have outlined.  I am use to it since I deal with a PMO on a regular basis. 🙂