Re: [scrumdevelopment] What is the credit for an unfinished user story?
- Hello, Doug. On Tuesday, September 1, 2009, at 2:05:18 PM, you
> When faced with this situation, due to unresolved impedimentsI prefer a sense of necessity to get things /done/ to a sense of
> etc., we re-estimated points for the remaining stories. The
> difference was the credit for the previous sprint.
> While a "game", it does provide a sense of progress for the team.
> In addition, it maintains some degree of rationality for calculating velocity.
progress. I prefer to calculate velocity based on things that are
/done/, not on things that are not done.
Adapt, improvise, overcome.
--Gunnery Sergeant Tom Highway (Heartbreak Ridge)
> > Don't re-estimate the story for the next iteration. You can ofI think this is different from just not being able to get a story done. However, even in this one I'd hesitate to change the estimate. That is, I usually don't like to change estimates for things done or ongoing, but if the understanding gained reflects on things not yet done, then I'd obviously re-estimate those.
> > course talk how much of the work is left (which should also be quite
> > apparent from the undone tasks), but don't change the total
> > estimate. Thus "the team gets the credit" at the end of the
> > iteration they actually complete the story, and this way your
> > average velocity is not affected by these.
> I would have thought you should estimate the story again. It might
> turn out that they didn't finish it because what they thought was a 1
> point story was actually a 3 point story - or more likely three 1
> point stories.
Velocity isn't so accurate anyways that a couple of stories isn't likely to change the average value in any significant way.
> Shouldn't the team use what they learned about the story, and theYes, 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."
> reasons for not completing it, and work with the product owner with
> that information?
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland
- 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.Better: We need to break these stories down a bit more ...
> "This story proved to be larger than we thought. We need to
> increase the sizes of similar stories in the future by a bit."
You do ill if you praise, but worse if you censure,
what you do not understand. --Leonardo da Vinci
- We follow pretty much same concept as Doug mentioned.As it is called generally Hangover of stories, in our next sprint planning we take that user stroy and reassess on how many worth of points we achieved and how much we are carrying to next sprint.The one achieved in last sprint goes for counting under Sprint Velocity for that sprint.Thanks,Sumit
Love Cricket? Check out live scores, photos, video highlights and more. Click here.
- I d see hangover stories as a problem and try to minimize such
unfinished stories by fixing issues around it.
Playing with numbers and counting story points of hangover stories. We
do sprint estimation by real days so
if there are unfinished stories, we estimate the remaining work and
the story is counted in the velocity once it is "done done done"
On Thu, Sep 3, 2009 at 10:00 AM, SUMIT
> We follow pretty much same concept as Doug mentioned.
> As it is called generally Hangover of stories, in our next sprint planning
> we take that user stroy and reassess on how many worth of points we achieved
> and how much we are carrying to next sprint.
> The one achieved in last sprint goes for counting under Sprint Velocity for
> that sprint.
> Love Cricket? Check out live scores, photos, video highlights and more.
> Click here.
- Interesting 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
- --- In email@example.com, "sten.johnsen" <steoj@...> wrote:
>1. The answer is 0
> I've been serving a team of 8 as a scrum master for 6 months. I must admit it has happened that a user story or two was not completed by the sprint demo. Usually only a few tasks left, but nevertheless no storypoints awarded for those.
> Also equally usually the PO wanted the story completed during the next sprint and during sprint planning the size of the story is a lot smaller in story points now than in the previous sprint.
> How does people do this. Does the team get the credit for the origianl storypoints when they finish the user story during the next sprint or do they only get credit for what was planned for in the sprint they actually completed it?
2. Credit is a meassuring business, remember the sentence:
"We're not in the meassuring business. We're in the delivering features business" Inglorious Programmers 2009
3. It happens, again and again in our team (like 0-10% in storypoints)
Work on it, it's the "game" of the really skilled teams that deliver 100% and on time. If you get worries about this, remember how all things have been before scrum. ;). I guess the delivering all on time mantra is the very basic reason why scrum teams have very high productivity values.