4

There are two common reasons why stories or bugs get pulled into a sprint in Scrum (where I work):

  1. Issue was triaged (usually critical/blocker field issues)
  2. Sprint was underestimated, and thus items from the backlog get pulled in to keep people busy

In both cases, most items (especially bugs) do not have a story point estimate or time estimate. The first question is: Is it important to have story point estimates on these items before they are brought into an ongoing sprint? And if so, when and how should this estimation take place? We only have sprint planning every 2 weeks (our sprints are two weeks) and I'm assuming it's unproductive to schedule a sprint planning meeting for every bug we bring in.

We use JIRA + JIRA Agile as our tooling to track Scrum sprints. The only functional reason I can think of needing proper estimation for are the reports. Also I worry our velocity will be negatively impacted if we pull in items into the sprint without an estimate.

Improve this question

4 Answers 4

Reset to default
4

We are using Jira at AOL right now, so hopefully I can provide some Good Practice and practical advice.

First off, let's separate this into two answers: New User Stories, Defects/Bugs

Defects/Bugs added in a Sprint: Don't Estimate- Reduce Capacity

So at AOL we face this issue a lot. We run a digital advertising system so it has a lot of customer escalation. We don't operate a maintenance team, so bugs end up with the feature development teams. Recognizing that interrupting a sprint is bad, we took a hard look at bugs.

We made an agreement with the business that only show stopping bugs (Blockers) could interrupt a sprint. When a Blocker comes in, it gets immediate priority. It isn't estimated and isn't even part of the official backlog. It is side work that has to be done and impacts the team's capacity.

All other bugs get assigned to the backlog. We run in two week sprints and have at least two teams per feature area so there is always a team starting a sprint every week. These bugs get groomed and estimated per normal.

With Jira we maintain a separate "Defect" backlog (specifically issues found in production). This backlog is groomed by a triage team and then all feature teams have access to it. During sprint planning teams are instructed to take roughly 20% of their capacity if Technical Debt. First priority in Tech Debt is always current production defects. This usually translates to our teams working on 1-2 bugs a Sprint, in addition to their new feature work.

New User Stories pulled into a sprint - ALWAYS ESTIMATE

A healthy product backlog should have two to three sprints of "Ready" work. That is stories that meet the INVEST criteria for a User Story. If you don't have this, then that's a bigger issue to tackle, which will make your team much more effective.

If you don't have a well groomed backlog, then what you want to do is take the time to groom new stories. If you are halfway into the sprint and there is no work to be done, then have a one hour meeting and groom the very top of the backlog.

This is critical, not just because you want all stories estimated. Taking in a story that is not fully defined is a great way to waste effort.

  • The Story could not be important anymore
  • The story could be ill defined and a lot of time wasted on re-work to meet "Done"
  • The story could be ill designed and lead to bugs in the system.

Poorly written user stories can take up to 24x longer to fix, than they took to write the first time (based on research by Jeff Sutherland).

Beyond the above advice, the single biggest thing I would recommend is holding regular Backlog Refinement Meetings. The Dev Team and the Product Owner working together to ensure your stories meeting the INVEST criteria. A lot of teams are used to having a "Definition of Done". You also need a "Definition of Ready", what does the story have to have before development can be started.

Improve this answer
2
  • So in JIRA speak, you have one scrum board for bugs and another for features, but you only create sprints on the features scrum board? How do you have it setup?
    – void.pointer
    Commented Feb 9, 2016 at 19:10
  • The team board is based on a filter that draws on the Feature "project" and the Defect "project". Projects and team boards can be totally different things. We have multiple teams pulling from the same "project" for their Team boards.
    – Joel Bancroft-Connors
    Commented Feb 10, 2016 at 3:00
1

Yes you should estimate any stories that get pulled into a sprint, especially if you consistently estimate all stories during sprint planning. The value of the estimate is primarily in the discussion around how the estimate is derived. The estimation process helps the team discover risks, requirements, and makes implicit assumptions explicit.

As for defects, it depends on your process. If you never estimate defects, then don't start estimating them. If you estimate defects during sprint planning, then estimate defects when they get pulled in as well. Consistent practice of estimation techniques (no matter if they are accurate or not) will make your velocity metric a useful tool for the team in their ability to plan sprints in the future where not as many items get pulled in.

Improve this answer
0

If bugs and production issues occur frequently, then you could add some unplanned time to your sprint as explained in Mike's blog https://www.mountaingoatsoftware.com/blog/how-full-to-fill-a-sprint.

You should estimate the new stories that are pulled in before starting work on it. This should be a quicker and shorter session than the normal sprint planning as you are only taking into account the new stories. When you are doing sprint planning, you could select a set of potential candidates (stories in the backlog which are on top priority) to pull into if your team run out of work.

But if that is a regular occurrence, then you should review your planning for you might be not considering the total capacity/velocity of the team.

Improve this answer
0

Assuming you'd like to be Scrum Guide compliant.

Is it important to have story point estimates on these items before they are brought into an ongoing sprint?

By definition each and every Product Backlog Item should be estimated. Therefore each and every Sprint Backlog Item should, as well.

[...] when and how should this estimation take place?

Estimation can happen anytime throughout the Sprint. Scrum Guide only requires Sprint Planning as mandatory before the next Sprint begins. That's the last chance to estimate any new Product Backlog Items. It doesn't say you're not allowed to have additional planning sessions. Backlog Grooming or Refinement, as it's called, is a very popular and recommended practice.

[...] I'm assuming it's unproductive to schedule a sprint planning meeting for every bug we bring in.

Correct. For bug handling in Scrum, take a look here.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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