55089Re: [scrumdevelopment] Re: Velocity Question
- May 9, 2012+1 Ron -- Thank you for taking the time to post a thoughtful and insightful response.-------
From: Alan Dayley <alandd@...>
To: "email@example.com" <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>
Sent: Wednesday, May 9, 2012 1:14 PM
Subject: Re: [scrumdevelopment] Re: Velocity Question
Just when I thought this thread was getting to long, Ron posts this excellent treatise.Thank you, Ron!Alan
On May 9, 2012, at 10:58 AM, RonJeffries <ronjeffries@...> wrote:Hi Bret, and all,On May 9, 2012, at 11:35 AM, Bret Wortman wrote:I invented points, and I can tell you that this is not what I had in mind when I did it."Credit" for getting things done, vs how hard they are to do, is simply not the point at all.In Sprint Planning and execution, there are two things to think about that I would like to address here:We need to know how much to sign up for.First of all, it is useful for the TEAM to have an idea of how much work to sign up for. At the time points were invented, we were doing this by a thing we called "perfect days", where we thought "if people left us alone to do this, we could do it in n days". People found that the term "days" confused managers and product owners, who would say, five days later, "but you said it would be three days". So we converted days to points in our heads, and said the story was a three point story. Then we paid attention to how many points we did in a Sprint, and used that number to guide how much we would commit to for next time.PO and management need to know how much work we'll get done over time.Second, it is THOUGHT TO BE USEFUL for management and the Product Owner to have a sense of how much product they can have done by some future date. (This is nowhere near as useful as it it thought to be, as it is always always evidence of dysfunction if people are very interested in this at all. I'll come back to that.)Points are only good for one of these two things.Points are fairly good for deciding how much work to take on.Stories actually completed per Sprint is fairly good for guessing how much product you'll have by some future date.THESE ARE NOT THE SAME THING. You cannot reliably use points to decide how much product you'll have. (You can use the number of stories actually completed to guess how many stories will be completed next time: it's just necessary that they all be approximately the same size.)Manage by results, not by effortPoints represent effort. It is very bad management to value the team in the amount of effort they put in. We do not want effort: we want results.Finished stories represent results. We should value the team in terms of results, namely in terms of stories.Claiming credit for points is direct evidence of dysfunction.The entire exercise of deciding how many points to assign to a story remainder, so as to "claim credit" for the points, tells us that the organization is valuing effort, not results. This is very bad.Story done? Count it. Story not done? Don't count it.Need to decide how many stories to commit to? Keep in mind everything you know, and any code that might be useful. This is not about credit, it's about knowing how much work to take on.Do not confuse planning with promising.Do not confuse inquisition with improvement.There's another dysfunction lurking still. The same people who care how many points you do will likely care how many stories you do. They will show this by saying "You PROMISED me ten stories BUT you only did eight! What is wrong with you?"In Scrum, the purpose of Sprint Planning is to decide how many stories to get completely done, with high quality, by the end of the Sprint. The team can use any means whatsoever to decide how much to take on. The entrails of goats have been used to good effect on some teams, and it it works for you, do it.Sometimes we do not get done what we thought we could. This is not a matter for comparison of estimates and actuals, much less creative accounting for next time. This is a matter for a whole 'nother part of Scrum, the Retrospective. In the Retrospective, we sit down and say "We thought we'd get ten. We got eight. What happened? What shall we do about it?" There are many possible answers, leading to many possible improvements:
Nowhere on this list will we see "we thought it was a seven point story but it turned out to be an eleven", because we can't stop there. We have to say what the four points where that we forgot, and figure out what to do so we won't think we can do what we couldn't do.Comparing estimates and actuals is weak Scrum at best.Concern for estimate vs actual is at best an indicator that we need to Inspect and Adapt, and it is not as good an indicator even then as "We thought we could do ten stories and we did only eight", because it requires more analysis to think about it, and it leads us down a line of thinking that is not productive.Counting stories is easier to do and helps avoid dysfunction.Therefore, it is best to make stories close enough to the same size so that counting them is a good first cut at guessing what we can do next Sprint. (Then as we plan the Sprint, we consider them in as much more detail as needed. The estimate numbers do not help us with this, so we should not use them.)Inability to work by counting stories is itself evidence of an impediment.If we cannot guess how many stories we can do because the team members are specialized and all we can do is add up their individual guesses, we have just identified a major problem: we are not a very well integrated team. We need to learn to talk quickly about a story to give a quick cut at how long it will take.Don't confuse planning with promising.Don't confuse improved planning with improved performance.Don't confuse better estimating cost with producing more value.Here's my advice:When stories do not get done, use the Retrospective to improve how we work rather than call for "better estimates". Continue to use history in Sprint Planning to guess how many to take on next time.Do not mix the idea of points, and the idea of completed story, together. One is cost, the other is value. Value is more important.
- We got interrupted by (the boss, meetings, ...). Let's reduce interruptions.
- We had to fix a critical defect. Let's bear down on testing and pair programming, so as to reduce defects.
- We got pulled off to work on another project. Let's cancel the Sprint next time, so management will realize they are screwing up their own project.
- We thought Story Six was going to be easy, but we didn't understand it. Let's be sure to get more explicit completion criteria.
- We thought Story Six was going to be easy, but we forgot that it required building new indexes in the database. Let's make a checklist of questions to ask about a feature and make sure database changes are on the list.
- << Previous post in topic Next post in topic >>