10

We are in the middle of our first Sprint and something dawn on us: we over estimated!

We had planned 114 ideal hours for this 2 weeks iteration and at the end of the first week we finished the whole Sprint. What do we do now? The "book" says we should, and we will, get the next high priority items from the backlog. Though, how do we add them to the burn down chart? Do we re-write it to account for those stories as if they were there from the begining? Or simply add their estimates to the y axis in the day we start working on them (showing a 90o angle jump)?

Any feedback is welcome!

Improve this question

7 Answers 7

Reset to default
8

One of the purposes of having a burndown chart is to show how, over time and transparently, value is being offered.

The new users stories were not in the sprint at the beginning, so it seems somewhat tricky to pretend that they were. By adding them into the burndown chart at this time, you're showing accurately that the current level of estimation is still somewhat in its preliminary evolutionary phases.

This is good for you and for your product owner. It shows, and will show, how using this system of project management has and will enable you to become better estimaters.

You'll be able to see right from the beginning that you were over estimating, then under estimating, then over estimating some more but slightly less...and eventually you'll see the improvements in estimating as you go along.

I think estimating user stories is one of the hardest parts of a sprint and only once your team learn to evolve together will they become more and more efficient at the process. It's good to have this demonstrated through the tools you're using such as the burndown chart.

Improve this answer
6

It won't hurt if you cancel the sprint, and plan the next sprint by taking your current velocity into account.

From the official Scrum Guide:

Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Team, or the ScrumMaster.

Since the sprint planning should be done within a discussion with the product owner, the scrum master and the team, it would be counter productive to simply pick the next user stories.

In the case you were slightly in advance, you could have picked the next highest prioritized story, but here your situation is very different.

Improve this answer
9
  • 1
    Beginning a new sprint when work in the last one is completed "too early" result in sprints with different lengths (ie not timeboxed)? Commented Jun 9, 2011 at 14:54
  • 3
    Martin Wickman: this is an exceptional action, required in an exceptional situation. Commented Jun 9, 2011 at 14:56
  • 2
    The Product Owner can (and should) cancel a Sprint if necessary. scrum.org/storage/scrumguides/Scrum%20Guide.pdf (page 11) Commented Jun 9, 2011 at 15:02
  • This does't look like a case where the scrum should be canceled. Just talk to the program owner to determine which stories to pull into the current sprint. Stories that can be finished in one week. Commented Jul 2, 2011 at 15:52
  • @Blake: that's how it is defined in the official scrum book page 11, see above. Commented Jul 2, 2011 at 15:55
4

You can add a burn up chart. They show, without ambiguity, when and how much new work you've added:

enter image description here

This chart shows the team added 20 more points of work in iteration 5. This image shows iterations, but it works just as well with days.

Improve this answer
3
  • 1
    I was under the impression that Burn Down Charts shows work remaining on a sprint in terms of story points while a Burn Up Chart shows the total delivered earned value to the customer. Story points and earned value are different - story points relate to time and effort required to complete the tasks as assigned by developers and earned value is the worth of each story as assigned by the product owner. Burn Down focuses on a per-sprint basis for developers, while Burn Up focuses on project level for managers and customers. Is this not the case? Commented Jun 9, 2011 at 14:31
  • 1
    @Thomas: Feel free to substitute points for value if that is important, or create two charts. You can use years, iterations, days or whatever time unit suits your project best. Commented Jun 9, 2011 at 14:40
  • Having been on a team that did burn up charts in terms of days, please do NOT do a burn up chart with days being the units. In our team, in a two week sprint, the first half week didn't show much activity, so management got nervous... even though the reason why there wasn't much activity was because of the meetings we had during the first two days... In my mind iterations are the perfect level of detail here. Commented Jul 6, 2011 at 15:45
3

There are a number of different techniques to visualize this.

One of them is to introduce an offset to the y axis (the horizontal axis) on the day the new stories were added, with the actual burndown graph then going below the original "0" level.

Another is to pretend they were there from the start (which is a lot easier of you use CGI based burndown graphs).

And you could come up with your own.

The most important thing is to discuss this between team, scrum master and product owner to reach agreement on what you want to do in this situation. There is no absolutely fixed way to do anything in scrum other than the basic rules. Scrum is meant to evolve over time to best suit the needs of your environment.

Improve this answer
1

I'd like to break down the OP's problem into three distinct questions:

  1. Continue or cancel the sprint?
  2. What to do in the remaining week if the sprint continues?
  3. How to plan the next sprint?

Burndown and burn-up charts mentioned in other questions, while useful, are secondary to the OP's "what do we do now?"

Continue or cancel: I'm with Pierre here, it is appropriate to cancel this sprint and start planning for the next one immediately. Sprint cancellation is not an option if there are other teams and sprints need to be synchronized (most Scrum gurus advise that they should be synchronized).

If the sprint continues: Limit work in progress. Work on only one story at a time, focus on finishing, for which you have less than a week. Make sure there are no stories in a partially finished state at the end of the sprint.

How to plan the next one: the options here are to try relative size estimation or use the story-point-person-day equivalence and the focus factor as an approximation as described in Henrik Kniberg's "Scrum and XP from the Trenches" book. We've discussed it already in a different thread.

Improve this answer
1

Getting completed in half the time is a huge variation off the estimates. To me, that would indicate a significant risk that what your team actually did deviates from what the users expected at the beginning of the Sprint. In addition, a Sprint is also supposed to deliver enough functionality that it's now time for new feedback from the PO.

So the risk in just grabbing stuff off the top of the PB and carrying on is that those items on the top of the PB are out of date (both in content and priority), and that your Team has gotten something wrong in the last Sprint and you'll just be building on those mistakes without getting feedback from the PO.

I'd say that the most reasonable course of action is to call the Sprint done, hold your usual end of Sprint review, planning meeting and retrospective and get started on the next Sprint.

As to the burndown chart stuff, the original question seems to miss the point of the what it's for. It's really just a tool to determine if you're having a problem with the progress during your Sprint. With what was described, the burndown chart should have come into play in this situation on about day 2 or 3 of the Sprint, when it would have shown that the Team was way, way ahead of schedule on the Sprint tasks. Then you ask the question "Why?", and determine if your estimates were just way off or maybe the programmers are mis-interpreting the tasks, or if something is going off the rails in some way.

But when you ignore the burndown chart and cruise on like there's nothing odd going on, then it looks like you're just treating it as some pointless artifact you're producing because the "book" tells you to. In my opinion, if you should decide to just pull some more stuff off the top of the PB and carry on for the second week, then just start a new burndown for the second week (and then you can ignore like you did the one for the first week).

Improve this answer
0

I would consult with the product owner on what work to do and add it to the current sprint on the date the work was brought in. One can track added work on the burn down chart. I don't have a problem with a burn chart that looks a bit like a roller coaster. This will happen anyway as the scrum members estimate the remaining time on tasks.

Sample Burn Down with added work

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.