I have 6 user stories for a sprint of 14 days. I have the detailed description in the stories for what the team needs to develop, and the team is new to scrum. (this would be their 2nd sprint). The only thing I haven't done so far is to assign an estimate to the stories, using a systematic approach. (like a point system). I want to start with Agile planning poker approach, but how do I assign a number of days after the developer assigns a size (number, color etc) to a story? My point is why do we need to have a point system if we are eventually going to estimate in terms of days?
3 Answers
The idea of story points is that allow you to measure how much you typically do in a sprint. Then you use this measurement to determine the capacity of future sprints.
Say you are about to start a sprint. Your team has a choice between two ways of estimating how much work will go in the sprint:
Time based estimating
The team looks at each story and works out how long they think it will take to complete. They also calculate how much time is available in the sprint. They add stories to the sprint until the sum of the estimates on the stories added equals the time they believe is available.
Story points estimating
The team estimates stories using relative sizing. They could use small/medium/large or they might use the Fibonacci sequence numbers (1, 2, 3, 5, 8, 13). The actual values used are not important. What is important is that stories requiring a similar amount of effort have similar estimates. e.g. two stories estimated at 5 points will take roughly the same amount of work to complete.
Now the team just gets on with doing some work. But the clever bit is they measure how much they get done in a sprint. They then use this measurement to determine their capacity for future sprints.
Say the team works for a sprint and completes 20 story points. There is a good chance that in the next sprint they will also do around 20 story points (as long as their sizing is consistent).
Notice how time is never mentioned. It is simply relative sizing and measuring how much gets done.
answered Jun 16, 2016 at 10:47
I think you're doing it wrong. You shouldn't bother assigning the number of days to the story. Your team has 14 days to work on the stories. So estimating points to stories is your way to decide how much work can be completed during those 14 days. If the total points for a single sprint is too big or too small (you know this by reflecting to past sprints), then adjustments to the amount of stories might be required so that you can deliver what you "promised" in 14 days. I believe that's the way to go in implementing Scrum. Assigning number of days for stories based on their size is a step not required; it's not even useful.
PS: If you need to do time tracking, that's another story. Try reading this Q&A for a start: Scrum - Is a good practice to set the remaining work of a Sub-task?
You'll be hard pressed to actually estimate how many stories you can do in the 2nd sprint. Particularly with a new team. Use it as an opportunity to practice point estimation and then use the the number of points completed (deployed to production) to determine how many points to pull into the 3rd sprint.
Here's the thing though... A single sprint's worth of data is practically worthless. A single data point just isn't enough to accurately forecast. They'll also be wrong about how big stories are. They won't agree about how big stories are. Problems will happen, expect it and don't knee jerk when they fail to finish as many points in the 3rd, or when they finish twice as many in the 4th. It's going to take time for a new team to find the sweet spot and their rhythm, but they will... eventually.
For perspective, it took my team a dozen iterations to achieve a stable, predictable, forecastable capacity. That's six months. Don't expect miracles. Just record the data, reflect, and adapt accordingly.
