Years ago, back when I was dumber…
Once every three months or so we'd have some incomplete story and we'd split the points, allocating some to this iteration and some to the next iteration. That's dumb.
Instead, for the last couple years when this happens I give no points to this iteration and points remaining (we estimate the remaining work) to the next iteration. Back then, the lower velocity would have caused angst in upper management, but read on.
We estimated our stories in points. We did not estimate our tasks. Our tasks were very fine grained. Most tasks were half an hour to half a day. We did not come up with tasks in planning. I wouldn't change any of that. In fact, it's what I currently try to get my clients to do. The difficult part seems to be the very fine grained tasks.
For us, 0 and 1 point stories were trivial. Normal estimates could be 5, 10, 15, 20, 30, or 40 points. If it was 40 or below, the story could go into an iteration. We would also use 60 and 100 point estimates, but those stories had to be split. Our problem was that the 30s and 40s were always underestimated relative to the 5s through 20s. The scale wasn't linear. We knew this. Knowing it didn't fix it. That made our velocity unstable.
Our unstable velocity caused lots of heart-burn in the upper management ranks and contributed to a lack of trust. If I had a do-over, I would solve this by narrowing the range of estimates allowed which would drive more of the larger stories to be split. I'd limit the range to, say, 5 to 20.
I've also considered solving an unstable velocity by clearly setting a high level of commitment for each iteration. Not stretch goal. Not aggressive goal. A high level of commitment. The team would of course still say what they would commit to. But I would have expected them to meet it. (This has sense been deemphasized in Scrum, and I didn't do it then and I wouldn't do it on most teams now, but it might have helped in this situation, as I describe next.) This surely would have initially led the team to commit to a smaller amount of work. And it would have eventually led to more care being made at the start of the iteration and in advance of the iteration in order to have a well thought out plan. We would have gotten back to committing to the normal amount of work over the long term, but would have given us a much more stable velocity and more predictable pace. Maybe. If done wrong it would have just angered the programmers.
Another way of getting at smaller stories and better planning would have been for us to drop from two-week to one-week iterations. That would also force us to split the larger stories. We already had a great design/task-creation/review approach, but we did that design just in time, during the iteration, immediately before development. With one-week iterations, we could do that work for each story on the 1st day of the iteration between planning and commitment.
And yet another way to crack this nut would have been to switch to a cycle time metric (as in Kanban) or publish only an average velocity measured over four to six iterations.
A blog about product development, product management, team and program management, lean, agile, and software development. Occasional posts about bicycling, Christianity, or racism.
Someone wrote to me with a couple excellent questions that the post should have covered:
ReplyDelete> I agree with you, but help me understand the advantage of NOT giving any points for an incomplete story this iteration YET STILL re-estimating it to reflect ONLY the WORK REMAINING in the next iteration.
Correct, I wouldn’t want to give all the points for the story in the 2nd iteration -- I didn’t actually complete that much in that iteration. I and most people give more weight to the recent velocity, so it’s easier in the next iteration planning meeting to know that we completed N points and not have to have the conversation about “yeah, but we actually only completed fewer points because…”. Also, I don’t want to forget in 2, 3, 4, 5, 6 weeks from now that iteration X’s velocity number is inflated. I don’t want to have to monkey with the numbers in excel if that’s where I’m keeping track and I don’t want to have to remember to monkey with the numbers reported by whatever tool I happen to be using and I don't want to have to explain to people why there is a discrepancy between the number I'm using and the number in the tool...
> Doesn't this artificially make the team velocity appear lower? And why is that ok?
I’m so afraid of over-committing to a release, most of my decisions about velocity err on the side of a lower velocity. There is so much unknown, so many details that have been overlooked, so many stories that just have to get done that we haven’t discovered yet, so many dependencies that might not play out right, so many things that can extend the schedule, that I want to under-commit at every step of the way.
It just occurred to me that I argue exactly the opposite on occasion. There are 2 good reasons to split the points:
ReplyDeleteFirst, if you reduce the size of the story, you will in effect reduce the scope of the project. The original backlog was 100 points, now its 97 points, but nothing changed. I wouldn't want the size of the backlog to go down unless the project actually got smaller.
Second, I also want to reinforce relative estimation at a high level (as opposed to a low level, with much detail at hand). Once you've had iteration planning for a story, once you've started to develop a story, it's no longer fair or accurate or appropriate to attempt to point that story. You now know the story more intimately. You know more detail. It's now almost impossible to estimate that story in the same way as all the others (at a high level with much uncertainty and relative to other stories that you know little about).
Unfinished stories absolutely suck.