I attended your training class a couple of months ago. We are continuing along with our scrum process, and we are learning a lot. I have one question – hope it is ok to ask. We did story point estimation as part of our team’s Sprint planning, and came up with the total story points that we were going to tackle for the sprint. As we started working on some of the tasks, we realized that they were more difficult then we had originally estimated. Also, some people finished their tasks early and picked extra stuff from the backlog.
My question is as follows: Do you ever change the total story point value in the middle of the sprint (for either of the reasons that I mentioned above), and it if so, how would that work if your burn down is based on story points vs time. I know we talked about it in class, but I can’t remember the answer.
I remember asking my own Scrum coach the same question a few years ago.
Scrum teams often estimate User Stories (or other Product Backlog Items) in “story points” using a “planning poker” estimation game to get the whole team’s input. This first pass rough estimation is done at the Product Backlog Item (PBI) level, to help keep the Product Owner aware of return on investment (ROI) when prioritizing work.
The estimates themselves are notoriously inaccurate. But getting everyone into one room to do the estimation forces us to have conversations that lead to clarifying the items and splitting them into thinner vertical slices of product.
During the Sprint Planning Meeting, the team looks more closely at the PBIs which are being considered for one fixed-length, fixed-scope Sprint. They rewrite them a bit, break them down into Sprint Tasks, and negotiate how much they can do in one Sprint. I suggest estimating Sprint Tasks in hours, and breaking them down when they’re bigger than 8-12 hours.
How does the team know how much to commit to? The PBI story points and the Sprint Task hours help. But really it comes down to gut feel and learning from the previous Sprint. I never expect teams to exactly nail the first couple Sprints. I personally prefer to keep Sprints short (like two weeks) so we learn faster.
Once the PBIs are committed to a Sprint, their story point estimates have served 90% of their purpose. Their only remaining purpose is to measure velocity to help inform release planning.
Should we re-estimate?
What should we do when we’ve committed work to a Sprint, and now we’re in the Sprint and it’s harder than we expected?
- Increase the appropriate Sprint Task estimates, or add new Sprint Tasks to the taskboard (or tool).
- Leave the PBI’s story point estimate the same!
- Relax. It’s normal. This is why the Sprint Burndown Line often goes up before it goes down, and why trying to draw an ideal line probably won’t serve you. If the line’s still trending up halfway through the Sprint, the team may want to renegotiate the commitment with the Product Owner.
If we committed to a small-looking PBI which turned out to be large, why shouldn’t we give ourselves velocity credit for a large PBI? Because this would skew our velocity too optimistically for realistic release planning. There are other small-looking PBIs in your release backlog which will also turn out to be large. Icebergs look small from a distance.
So the answer to your question is “no.”
Is collaboration occurring?
I have a second concern about your team.
If I understand your email, some members fell behind, while others got “their tasks” done early and picked up new work from the Product Backlog, beyond the original commitment. I’m not yet inspired by your team’s collaboration.
For the simple, low-risk work of Frederick Taylor’s era, individuals (such as bricklayers) working on tasks in parallel seemed more “efficient.” For the complex, high risk work that Scrum’s intended for, I’ll bet you’ll get better results by helping each other out more. I wouldn’t recommend individuals work ahead of the Sprint commitment until the team’s committed work meets its acceptance criteria.
Yeah, collaboration entails learning new skills. But it brings a great opportunity for higher performance. The Sprint Retrospective is one opportunity to address this.
Hope that helps!
Download the PDF version: Should Scrum Teams Re-estimate Work in Progress blog