Sizing tickets Approriately in Scrum

Question

In scrum how do you handle sizing things accurately without overcommiting and still keeping the team honest?

In my agile team I am seeing us size things large with some buffer, usually 2 or 3 points larger with typical ticket sizes 5 and under, to account for mistakes in the sizing so we don't overcommit in our sprints.

When our Sprint Velocity is around 20, and a developer is working on a 5 point ticket, they are going to make sure they take most of the sprint doing that work, whether or not it truly is that large, because the pressure is gone.

Answer 1

When our Sprint Velocity is around 20, and a developer is working on a 5 point ticket, they are going to make sure they take most of the sprint doing that work, whether or not it truly is that large, because the pressure is gone.

Your team is using sizes wrong. They are an estimate of amount of work a story requires compared to others, not compared to any fixed amount of time. And they are simply an estimate.

At the start your estimates will be all over the place, but as you finish sprints you should be looking back at the estimates and the reality and learning from that to improve the estimates for future sprints. Your estimates should be getting better as you learn about the project, the team, the technology etc. You should be tracking if your estimates are getting better or worse and self correcting. For example if your estimates are still away off into the project then there is a problem with the information the team have about the stories they are being asked to estimate.

They are not commitments to get X done in Y amount of time. There should not be any "pressure".

Answer 2

We use this procedure:

1. When writing PBIs, we use story points, which are a measurement that is only meaningful in the context of velocity.

2. As the iteration comes to an end, developers work out the task breakdown for PBIs that are candidates for the next iteration.

3. With the task breakdown, the developers estimate actual hours

4. When the iteration kickoff arrives, the developers will have already decided on the task breakdown and the work required. This greatly improves accuracy and confidence.

5. In the kickoff, for each PBI in the backlog, examine the task breakdown and hours estimate; the developer himself/herself must agree that (s)he is comfortable including the PBI in the iteration.

6. If a developer does not have enough information to break down a PBI into manageable tasks, the PBI goes back to the backlog for further grooming.

Answer 3

It sounds like you are using story points incorrectly. Story points are relative to each other for this team only, and nothing else. For the very first sprint you have nothing to compare points to so you have to make educated guesses. After that, it should become easier and easier to be consistent in sizing.

With each sprint except the first, pick a previous story that seemed to be sized approximately right and is vaguely "average" for however you want to define that. If you don't have any stories that were properly estimated, pick a "typical" story from the past and decide what points it should have had using your 20/20 hindsight. Whatever story you pick becomes your new standard.

Next, pick a new story and simply ask yourselves if this is considerably easier, about the same, or considerably harder than this previous story. Don't think at all about how much time it takes to complete the story. Don't think "well, this will take two more hours", think "this is half as hard" or "this is twice as hard". That's all you have to do.

If you've estimated something as 5 points, and it took 4 hours longer than the previous 5 point story, don't worry about it. If it took a few hours less, don't worry about it. Those are all 5 point stories. You can start worrying about it when you size a story as 5 but it takes as much time as most 8's.

When you become better at recognizing similar sized stories, estimation becomes easier and easier. You will be off by a lot for a few stories, but you'll be short on some and long on the others, and it will mostly even out.

TL;DR: it's important to remember that the points mean nothing, and velocity is an indicator. What matters is consistency. Virtually every 5 point story should take more time than a 3, and less time than an 8, but if one 5 point story takes 8 hours and another takes 12 or even 16, that's probably ok as long as it's still less than an 8 point story.