This post outlines the key points in favor of estimating user stories in story points. These include:
- Story points help drive cross-functional behavior
- Story point estimates do not decay
- Story points are a pure measure of size
- Estimating in story points is typically faster
- My ideal days are not your ideal days
Story points help drive cross-functional behavior
Agile teams include members from all disciplines necessary to build the product, including programmers, testers, product managers, usability designers, analysts, database engineers, and so on.
Estimate in story point presents a single number that represents all of the work for the whole team. Thus Estimating in story points can help teams learn to work cross-functionally.
On the other hand Estimating ideal days, often involves specialty groups estimating how long "their part" of a story will take and then summing these sub-estimates.
For example, the programmers may conclude that they need three ideal days, the database engineer needs one, and the tester needs two. An estimate of six ideal days is then assigned to the story.
This small difference in how the discussions about a story take place (to provide a single story point) have an ongoing impact on how the story is developed.
Story Point Estimates Do Not Decay Or Has Longer Shelf Life
An estimate expressed in story points has a longer shelf life than an estimate in ideal days.
An estimate in ideal days can change based on the team's experience with the technology, the domain, and themselves, among other factors.
To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days.
Now, jump forward a few months and ask the same programmer how long it will take to develop an application that is of exactly the same size and complexity.
His answer may be one day because he has become more skilled in the language.
We have a problem now because at two different times, even the applications are exactly the same size, yet they have been estimated differently.
We would like to think that measuring velocity over time would correct or account for this problem. It won't. Instead, we'll see a consistent velocity even though more work is being done. Suppose this programmer is the only person
on the team and that he is working in one week iterations. The first time he develops the application, he has estimated it will take five ideal days. Let's suppose he's in an environment where a calendar day equals an ideal day. He then starts this application on the first day of the iteration and finishes it on the fifth. He has a velocity of five for that iteration. Then, a few months later, because he estimates a similarly-sized application as one ideal day, he will complete five of them in an iteration. His velocity is again five, even though he did five times as much as work as before.
For some projects, especially those adopting new technologies or on which the team is new to the domain, this can be a consideration. Note that both story point and ideal day estimates will need to be updated if the size of an effort changes based on the development of a framework, for example. However, only ideal day estimates need to change when the team the team becomes better at something.
Story Points Are a Pure Measure Of Size
Story points are a pure measure of size. Ideal days are not. Ideal days may be used as a measure of size, but with some deficiencies.
As noted in the preceding section, an estimate in ideal days will change as a developer's proficiency changes. This does not happen with story points—the size is what it is and doesn't change. That is a desirable attribute of any measure of size.
Estimating in Story Points Is Typically Faster
Teams that estimate in story points seem to do so more quickly than teams that estimate in ideal days.
In order to estimate many stories it is necessary to have a very high-level design discussion about the story: Would we implement this in the database? Can we re-use the user interface? How will this impact the middle tier? are all questions that come up at one time or another. My experience is that teams estimating in ideal days have a tendency to take these discussions a little deeper than do teams estimating in story points.
The difference is presumably because when estimating in ideal days it is easier to think about the individual tasks necessary to develop a story, rather than thinking in terms of the size of the story relative to other stories.
My Ideal Days Are Not Your Ideal Days
Suppose two runners, one fast and one slow, are standing at the start of a trail. Each can see the whole course of the trail and they can agree that it is 1 kilometer.
They can compare it to another trail they've each run and agree that it is about half the length of that other trail. Their discussions of trail size (really distance in this case) are meaningful.
Suppose instead of discussing the length of the trails these two runners discussed the time it took to run the trails. The fast runner might say, "This is a six minute trail," to which the slow runner would respond, "No, it's at least a ten minute trail." Each would be right, of course, but they would have no way of settling their differences other than agreeing to always discuss trails in terms of how long one of them (or some other runner) would take to run the trail.
This same problem exists with ideal days. You may think you can completely develop a particular user story in three ideal days. I think I can do it in five days. We're both probably right. How can we come to an agreement? We might choose to put your estimate on it because we think you'll be the one to do the work. But that might be a mistake because by the time we actually do the work you may be too busy and someone else maybe doing it. And I'll be late because it's estimated at three days for you but will take me five.
What most teams do is ignore the issue. This is acceptable if all developers are of approximately the same skill or if programmers always work in pairs, which helps balance out extreme differences in productivity.
Happy Blogging!!!!
Regards,
Arun Manglick
本メールおよび添付ファイルは、機密情報を含んでいる可能性があります。そのため、宛先人以外の方による利用は認められておりません。宛先人以外の方による本メールの公表・複写・転用等は厳禁であり、違法となることがあります。万が一、本メールを宛先人以外の方が受信された場合は、お手数ですが、直ちに発信人にお知らせいただくとともに、本メールを削除するようお願いいたします。
The contents of this email and any attachments may include confidential information. Therefore, they may not be disclosed to, used by, or copied in any way by anyone other than the intended recipient and any such disclosure, use or copy can be treated as illegal. In the case this email is sent to you in error, please inform the sender and delete this email.
