Don’t you hate gathering metrics that don’t mean anything? In the 80’s it was KLOC (thousand of lines of code) in the 90’s projects got so big we had to do big bang waterfall estimates where nobody had a handle on how long it would REALLY take to complete a project. Now in the agile age we have story points but management still wants hour estimates so they can answer, “when is this done?”
All of these methods have issues with dealing with the unknown, risk, interruptions, attrition on and on and on.
I do like story point estimates. SCRUM and Paceline as well as other agile methodologies do estimate based on story pointing. A customer or product owner would describe an end user feature. The team would then apply a story point to the feature. One common method is use a fibonacci sequence of 1, 2, 3, 5, 8, 13. This was really effective and development teams would quickly have the same feel as to a story point based on amount of work, complexity and risk. Stories that were larger then 13 probably were too complex or too broad and would have to be either broken down or the product owner would rewrite the story. It is amazing how quickly the team sizes the story pretty much the same way.
Story point estimates are great because:
- They incorporate complexity and risk
- They are decided by the team
- Easy to size up an iteration once you have team velocity (number of story points complete in a cycle)
Where story points fall down:
- Management erroneously attaches hours to story points
Great article on story points vs hour estimates I recommend reading blog post from Jeff Sutherland Story Points: Why are they better then hours?
To address the deficiencies, the backlog is complete can be calculated by velocity of the team. Velocity of the team is known after several cycles have been completed. But then all the management what-if scenarios start being asked:
- What if I add this team member?
- What happens it this team member leaves or get reallocated?
- How many folks do I need if I want the backlog complete by 2nd quarter?
SCRUM tools out there do not do a good job providing this information so management and product owners can make decisions. There are other variables such as heads down time of the developers versus meetings they are attending but not coding.
Development metrics are not enough, I believe team management metrics are also in order and should be captured. Beyond story metrics, velocity should also be combined with:
Code blocks per week
Hours of coding per week
Average hours per code block
Why I think this is important is we all know interrupt driven development is unproductive. A developer working one block of 4 continuous hours will be more productive then a developer that works 4 blocks 1 hour each with meetings in between each block. Now here is a metric that management should focus on! An optimized work day for developers will have a higher velocity then an one that interrupt driven.
I would put forth that this should be measured by role: Team Lead, Developer, Test Plan Writer, Test Executor, etc.
Now if we had those metrics combined with velocity we can see how long it will take to finish this backlog of 50 stories and we now have metrics to make management decisions to try and make the team a productive as possible.
What metrics have you found to be useful?
