Explaining definition of story points to the dev team
[posted on https://www.scrum.org/Forums/aft/538 by accident before]
Hi all,
we've spent 12 sprints with planning poker and story points based on complexity. Our new scrum consultant said, that complexity as a measured variable/unit is still too time related and that people are still thinking in effort and time for implementation.
I think that he's right, since we used to determine the story points per day/person during our sprint planning to determine the amount of story points to pick. This is probably not the "spirit of scrum" ...
Our scrum consultant suggested to not consider story points in planning at all, but to ask the team after introduction of each story if they think that they can do it within the sprint. As far as I got him, story points are only used by the product owner in order to update the release plan with the teams velocity. And they're probably used by the scrum master in order to see performance changes.
What I liked about the consultant's suggestion is that they recommended to have three 30 minute estimation meetings during a two week sprint where you estimate the whole backlog each time. With this method people will probably be forced to deal with all items all the time. This will probably raise the awareness for and the quality of all backlog items.
The consultant recommended using magic estimation. We should compare the user stories relative too each other by guessing/estimating/measuring/imagining the number/amount of problems that the story solves for the customer. As an example he said that a nail solves less problems for a customer than a hammer which solves less than an electric drill.
I wasn't really able to transfer the idea of this measured variable/unit to the dev team, probably because I wasn't completely convinced either. They asked why they should determine the amount of use for the customer. This should be the po's job, they said.
I found some other suggestions online which recommend using t-shirt sizes or the level of understanding for a story. Our management (which introduced scrum and promotes it) said that level of understanding isn't enough, since you could also understand something that solves a lot of problems.
My questions:
1. Did I get the whole idea right?
2. Which measured variable/unit can be used for estimation?
3. How do I transfer that idea to the team?
4. Are there any other things that I overlook here?
Thanks in advance,
Flo
As no one else has answered, I'll give it a shot.
My guess is that if this is an experienced consultant, he is seeing something that I do not. Something about people being still too tied to hourly estimates instead of relative effort.
I'm not sure that I understand the situation, at first the consultants advice sounds a bit strange. Story points are a direct correlation to effort, although they are 'masked' somewhat which allows people to focus more on size than on a metric like hours. Truth being we do not estimate effort in hours very well. The PO can do calculations of hours/story point or story points/release to project costs and/or delivery dates, but that is not the only use for story points. I think story points can also be a motivator for the team, I know my team is pumped when we deliver a large number of story points versus when we don't.
When using story points to project output, it should be based on historical data of velocity, that is how many story points were actually Done during a sprint. Story points/person or hours effort/story point are only guessing especially as story points can vary significantly from team to team. One team could have an 8 point story as a 'normal' story and another team could have 3. The beauty is that is doesn't matter the starting point, once you have a stable team (not changing members all the time) you will get a good predictor of output, although it will take some time (~5 sprints in my limited experience).
We do use story points during sprint planning to consider what to put in the sprint backlog. We use it as a guideline to know when to ask 'is this too much/not enough?'. It sounds like your consultant is asking you to have the dev team commit to the sprint backlog on gut feel every sprint, without using the assistance of story points to gauge how 'heavy' the sprint is. There could be merit in this approach if a team is being too strict about story points (e.g. we should always put 50 story points in the sprint and when we hit 47 we should only put a 3 point story in regardless of business priority). But I would say it's a tool you can use - compare velocity to story points and see if it makes sense but the team should always decide what's in the sprint.
Three 30 minute estimation meetings sounds like encouraging backlog refining to me, which is good, but in my world I don't think we could go through all of the backlog in 30 minutes, even if we focused on just the stories for the next sprint. Probably in the first meeting we would go through 1/3-1/2 of them, in the second 1/2-3/4, and in the third 3/4-1. So I can see this working as a way of increasing understanding of the stories as they get closer to being implemented. And having multiple meetings like that could help the PO go back and get clarification on the questions that came up. So depending on the context, and assuming that this means you go into sprint planning with a fully dressed and understood story (which means less time in planning) this makes sense.
I don't understand why the consultant is suggesting the team should be estimating the business value of a story. To me this is totally divorced from the effort of the story (which the team should be able to understand and determine for the PO). It is the POs responsibility to prioritize the stories based on business value. He or she may change the priority once it's determined that one story is 3 points and one is 13 and they both have similar value, but that is not a determination that the team should be responsible for (in other incarnations of agile yes but not scrum where you have a PO). It's up to the PO how to do this, could be a value point system working on a Fibonacci scale or whatever. I agree with your team on this point.
Finally, short answers to your questions:
1. Which idea? Story points? Not sure, hopefully my feedback gives you some ideas.
2. Estimation of effort? Story points and velocity. Estimation of value? PO's responsibility.
3. Focus on relative sizing of effort. We are bad at predicting how many hours something we will take. We are (relatively) better at estimating that one task will take longer than another.
4. Not sure, I hope the above sparks some ideas for further questions.
>> 3. How do I transfer that idea to the team?
> 3. Focus on relative sizing of effort. We are bad at predicting
> how many hours something we will take. We are (relatively)
> better at estimating that one task will take longer than another.
To do this, try playing "the estimation game", or team sorting as it is sometimes called. It discourages team members from trying to over-analyze the numbers. You can start off using t-shirt sizes and map points to them later.
See: http://agile.dzone.com/articles/agile-estimation-practice
With all the Teams I play the same game which is actually the Affinity Estimation + Estimation NET game.
You can see find it here http://www.smartagilee.com/2013/11/blog-post_4.html (the text is in russian, make sure you choose english for translation)
Posted By Ian Mitchell on 19 Nov 2013 06:26 AM
>> 3. How do I transfer that idea to the team?
> 3. Focus on relative sizing of effort. We are bad at predicting
> how many hours something we will take. We are (relatively)
> better at estimating that one task will take longer than another.
To do this, try playing "the estimation game", or team sorting as it is sometimes called. It discourages team members from trying to over-analyze the numbers. You can start off using t-shirt sizes and map points to them later.
See: http://agile.dzone.com/articles/agile-estimation-practice
thanks for all your replies. I haven't figured out the intention of the "number of solved problems" idea yet and I was glad to see, that you didn't understand it as well.
I had quite a good magic estimation with "level of understanding". I used a custom scale like "could start immediately", "one tiny question" .... "give me 10 minutes with the po" and "WTF" and felt that the team could identify themselves with it.
Since the PO tried to get the remaining questions answered almost all of the stories were set to "could start immediately" which in my pov killed the idea of having useful story points afterwards. Now we're in a sprint with only "level of understanding" and I have some doubts on how to calculate the velocity. But I could assign fibonacci numbers to my scale, I assume.
Because of this I will use "level of understanding" only as additional attribute of a story and will try to focus on shirt sizes in the next meeting. I think this complies with your suggestion for focus on relative sizing. Do you think that this is a feasible solution?
I'm not sure that I understand completely, but your "level of understanding" translates to me as "Ready" and would have nothing to do with Story Points (or relative sizing that we've talked about), which are a proxy of the level of effort to complete a story. The "level of understanding" says nothing about how long it will take to complete, just whether they know what needs to be done (which is a prerequisite to doing, so still useful before estimating). So it sounds like you didn't do effort estimation for this sprint, which is ok I guess but doesn't give you any useful information for velocity. If you want that you should have the team estimate effort.
So yes, in future you could use "level of understanding" as an additional measure of Ready, and then an estimation for level of effort/story points.
Thanks for confirmation.
Now I only need to find a way to make magic estimation work online and to generate more feedback to my PO about the problems with some of his stories. But this is probably going to far within this thread ...