5

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.

  • 6
    Points are merely there to show the relative effort of one ticket against another. If you're automatically equating points with time, then that is comparing apples and oranges with the inevitable results as you've seen. – Robbie Dee Jan 30 '17 at 15:13
  • 1
    If you have a developer who spreads a story out to fill an entire sprint, you have bigger problems than sizing stories. That person is not a team player. – Bryan Oakley Jan 30 '17 at 23:51
  • Related: pm.stackexchange.com/q/20239/21039 – RubberDuck Jan 31 '17 at 2:12
  • @BryanOakley, interesting, so maybe the problem is less with our process and more with the team getting demoralized. – Chris Jan 31 '17 at 3:15
  • @Chris: I don't know if it has anything to do with demoralization or not. Why are they demoralized? Scrum should be simple: if you overcommit, just bring fewer stories into the next sprint. The sizes are all relative and shouldn't be related to the amount of time it takes to complete a story. Pick and "average" story, and then size everything relative to it. Do you think it's about the same amount of work" Same number. Definitely less work, it's a smaller number. Definitely more? It's a bigger number. – Bryan Oakley Jan 31 '17 at 3:26
8

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".

  • Thanks, I think I understand that. The disconnect for me is how we communicate estimates to clients I guess. – Chris Jan 31 '17 at 3:06
  • 1
    Estimates on when a feature will be finished become clearer when you know your velocity is accurate. But that takes time. At the start it will be difficult to estimate when a particular feature will be released. This is true whether you give a guesstimate or not, so you are better off not guessing and waiting for the velocity to settle down. This is why priority is more important than estimation. You might not be able to assure exactly when feature X will be done, but you can assure them that feature X will be released before feature Y and Z. – Cormac Mulhall Feb 1 '17 at 16:46
1

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.

1

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.

  • Sorry, must have been a brain fart - I've removed my comment. – Robbie Dee Feb 1 '17 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.