Another installment on the Nokia Test.
Before we begin, a quick mention that Jeff Sutherland has done an improved scoring on the Nokia Test. See here.
So, the next item on the test says: "The Product backlog has estimates created by the Team."
Why is this important and what does it mean? Meaning first.
So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn's book:
Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can't bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that's a bit different.)
And these estimates are created by the Team of implementors. Those who will do the real work.
Why?
Well, estimating my own work gives me much more motivation. And responsibility. And a reason (well, another reason) to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don't have the same feeling.
Yes, there is a downside. Not every Team is equally good at estimating. Yes, it's true. But we are convinced that the negatives are more than offset by the positives.
Another key reason for this test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:
Before we begin, a quick mention that Jeff Sutherland has done an improved scoring on the Nokia Test. See here.
So, the next item on the test says: "The Product backlog has estimates created by the Team."
Why is this important and what does it mean? Meaning first.
So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn's book:
Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can't bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that's a bit different.)
And these estimates are created by the Team of implementors. Those who will do the real work.
Why?
Well, estimating my own work gives me much more motivation. And responsibility. And a reason (well, another reason) to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don't have the same feeling.
Yes, there is a downside. Not every Team is equally good at estimating. Yes, it's true. But we are convinced that the negatives are more than offset by the positives.
Another key reason for this test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:
- Tell some managers: "Look at our velocity. We are going at 20 work units per Sprint. Stop hoping and dreaming that we will go at 40 work units. It's magical thinking and it ain't happening. And your trying to make it happen is just making things worse."
- Tell ourselves: "Folks, we're going at 20 Story Points, but we need to do better. Let's identify a top impediment and FIX IT. So that we can go 22 or 25. Now! (But not by working harder.) "
- Face the truth. Velocity is a way to help us all face the truth. And take action. (Ex: If you name an impediment, someone is going to ask: "Ok, what do we do about it?")
2 comments:
Nice blog dear i have really learn a lot from this blog thanks.
Glad you did. "To know and not to do is not to know." So I hope you are putting it into action. Regards, Joe
Post a Comment