41110Re: What is the credit for an unfinished user story?
- Sep 4, 2009Interesting thread. Lots of different ideas. FWIW I'm on board with Ron. If you can just count the stories, that's best.
I think there is a prerequisite to being able to just count the stories. The team has to learn to break stories down into a small size, such that differences between the size of stories aren't significant enough to affect short-term planning.
I've found that a good way to influence teams in that direction is to shorten the iteration length so that they don't have enough of a cushion to define large stories. One week seems to work well. But that's only a mechanism to help drive story size down. If you can define small stories and still work with a longer iteration, that's okay too.
Not all teams are "ready" for that. A large story can blow their iteration out of the water if they don't realize how large it is. Next best, I guess, is to size stories in terms of an abstraction like Story Points. IMHO the team should continue to improve its ability to break stories down and eventually outgrow the need for sizing. Sizing is lighter-weight than estimation, but it's still overhead.
When I read/hear people talking about ideal time, it strikes me as perhaps the least mature application of agile thinking of the three (commitment, points, ideal time). I'd suggest people be careful about fooling themselves with word-tricks. People who peg "points" to time (for instance, "one point is equal to 4 hours of ideal time") are still thinking about time and still "estimating" rather than "sizing". That's a smell. If you cover the smell with pretty words, you deny yourself the opportunity to improve.
I don't think any of these approaches is "wrong." I think they just represent different levels of maturity in agile practice. I think that any reference to time in the estimates is a process smell the team ought to discuss in their retrospectives, to see if they can move from estimation in terms of ideal time to sizing in terms of points. They should also do as Ron suggests and continue to improve their ability to break stories down.
I think it's okay for a team to push themselves a little too far, as a way to discover their (present) limits. So if you want to try commitment-based iteration planning for a couple of iterations, and you learn that things don't work so well, you can always drop back to story sizing or even task estimation, if that's what is workable in your situation at the moment. At least you won't have to guess at where your limits are, and you can set realistic goals for improvement.
Ultimately I think it's best if a team can keep work flowing smoothly and delivering value regularly, predictably, and sustainably. The lighter-weight the short-term planning process can be, the easier it is to achieve that level of effectiveness.
In order to get there, a team has to be aware that task decomposition, estimation in terms of time, and even sizing in terms of points aren't the "end game" in agile development. Otherwise, they might not realize there's anything to improve, and they'll settle into a comfort zone.
--- In firstname.lastname@example.org, Ron Jeffries <ronjeffries@...> wrote:
> Hello, petriheiramo. On Wednesday, September 2, 2009, at 1:21:15
> AM, you wrote:
> > Yes, and I don't mind the team bringing it up in retrospective.
> > "This story proved to be larger than we thought. We need to
> > increase the sizes of similar stories in the future by a bit."
> Better: We need to break these stories down a bit more ...
> Ron Jeffries
> You do ill if you praise, but worse if you censure,
> what you do not understand. --Leonardo da Vinci
- << Previous post in topic Next post in topic >>