The two favored measures of estimation in Agile software development over the years have been Ideal Person Hours (original Scrum) and Story Points (XP, and later Scrum). Both fall short of being useful. The first, simply because software isn’t built by individual persons, but by teams, and the second because the system is too easily gamed—and it adds a level of indirection to the question customers really care about: how long will it take?
Joshua Kerievsky recently wrote a long post about why he and his teams no longer use story points, and describes the journey away from points. In the article he touches on Team Weeks:
“I coach teams to write user stories for their releases and estimate them using “team weeks”: the amount of time it will take the whole team to complete the work. It doesn’t matter if only 2 people on a team of 10 can do the work: just provide the estimate as either .5, 1, 1.5 or 2 team weeks”
In a healthy Agile environment we have cross-functional teams, i.e. teams consisting of all the skills needed to take an idea from conception to working software. Rarely does one person have all the required skills, but a thoughtfully formed team of people will have those skills between them. So estimation can never be done in person days or hours. This will keep us in the divide-and-conquer mindset, and encourage hand-offs from one person to another. As Joshua points out, it doesn’t matter if only 2 people on a larger team will do the work, the focus needs to be on team responsibility, hence team weeks—or, as is my preference, team days.
Very little has been written about this unit of measure so I was glad to see it brought to light in Joshua’s article. I have used this measure with teams on and off over the past few years and find it the most useful and meaningful measure. It seems to encourage realistic thinking, and generates engagement from team members during planning dialogs. Developers are actually very good at estimating, and being able to estimate in real time creates a more engaged and respectful dialog between team members and customers.
While story points do encourage team-think, they fall short in their abstractness, and there have been many cited examples of teams gaming the system, usually due to managers pressuring for “increased velocity”. There are only two weeks in a two-week sprint. There are only seven people on a seven-person team. Going faster can only mean going crappier.
Both Scrum and Kanban implementations can benefit from predictions of time-to-market. We know this is never accurate, but for marketing and sales departments to do their job, we owe them our best guess. Team Day sizing can be quick and approximate, but gives enough of a sense of reality for a simple calculation to be done on release dates—using measures that mean the same thing to all parties.
If you haven’t tried estimating in team days yet, give it a go. You may be surprised by the benefits. If you have tried them, I’d like to hear about your experience.
click to subscribe
Agile Anarchy 