Re: [scrumdevelopment] Size of user story and efforts
- +1 to this. It jibes with what I tell our teams -- look at the work, decide what you can do, and formulate a plan to get that work done. When that's done, we add up the estimates (which were generally done before this activity began) and see if it's close to our historical velocity. If we're close, great. If we're way off, we might want to ask ourselves whether our estimates are inaccurate or whether we think we're going to magically get more work done. Or if we're being unrealistic about the work we think we can do. But we do not change our plan based solely on what the "numbers" tell us.This is like something I learned when I was training to be a volunteer paramedic. "Treat the patient, not the monitor." When making a decision between paring the work down because we don't think we can do it, or because it's above our velocity number, I only tell the team to pare down in the former case. The velocity figure is a double-check, a sanity check, like an EKG. It's just one measure of what's going on with the team, and certainly not the only one. Better is the overall sense the team has of what it can accomplish.
On Mon, Mar 26, 2012 at 10:21 AM, RonJeffries <ronjeffries@...> wrote:
Hello Morgan,If I understood your question it was, approximately:Suppose we know our velocity with all people present.Suppose we are going to be two people down.We need to estimate how much to sign up forShould we
It seems clear to me that you know that a) is not going to get the right answer. Are we together so far?a) use our all-people velocity and sign up for thatb) adjust our velocity somehow to get an estimate to sign up forI would never recommend using an approach that will get the wrong answer. Therefore I cannot recommend a). I would have thought that you would feel the same way, because you seem to me to understand that a) gives the wrong answer.Therefore, by process of elimination, we must choose b), and adjust our velocity somehow.One approach would be to adjust by the percentage of time lost. In a very cross-functional team, this might work well. I hope it is clear that if the people leaving are somehow critical to all stories, we may not be able to get anything done. That would be bad. That also suggests that a "model" of how to estimate is going to be quite complex, possibly impossible to create.Another approach would be to look at the actual work to be done, as a team, and decide how much you can actually do. If the absent people are the only people who can do certain kinds of work, it would be imprudent to choose stories that cannot be completed without them. I hope that this is clear to you already.Therefore, if we must estimate numerically, it is clearly wrong to do a) and only probably wrong to do b), so we must choose b.However, if instead of doing all this numeric folderol we just sit down at a team and decide what we can accomplish, we'll surely get a better answer. We'll also get more team commitment and more team cooperation.This is why numerical estimation and tracking are generally not the best possible idea. Team coordination and collaboration work better on all dimensions.Regards,
- On Thu, Mar 29, 2012 at 04:48, RonJeffries <ronjeffries@...> wrote:Still, it is more or less true that you can guess that the number of story points will stay about the same from Sprint to Sprint. In fact, if you tell a team that they must do five more points every Sprint, they can do that.Can you figure out how they'll do that?
Wow. I think the penny just dropped.
Thanks, Ron--this question clarifies it better than previous explanations.
Tim Lesher <tlesher@...>