5

The burn down chart displays a clear deadline and the progress towards the deadline. When the progress is slow and the completion of the committed work is at risk, people start to get sloppy on design and code reviews and on the depth of testing. Quality suffers.

The question is whether in your organization you were successful to maintain high quality standards regardless of the time remaining to the end of the Sprint. Another question is whether perhaps it is best to drop the burn down chart to somewhat reduce the pressure or even move from Scrum or Kanban or other agile methodology that doesn't mandates iterations.

| improve this question | |
  • 3
    Could you reask this question as something that isn't polling for experiences? There's a problem somewhere down in there... but right now it appears to be asking for people's "yea, that happened to me too" type answers. – user40980 Mar 17 '14 at 14:22
  • But I am interested in experiences rather than theory. I think there is too much unproven theory, especially with methodologies, that is being thrown around. I do prefer concrete examples and experiences. – Eugene Mar 17 '14 at 14:25
  • 2
    Polling for experiences doesn't work too well in a Q&A format. The design of the site emphasizes the "here is the question with a problem, here is the one answer to the problem." Not that other questions aren't interesting, but they work poorly in this format. – user40980 Mar 17 '14 at 14:28
  • While I've answered your question, I agree with @MichaelT in that you should try to rephrase this question a bit. – BrandonV Mar 17 '14 at 14:41
  • 1
    Can you avoid prefixing questions with "Scrum:"? Prefixing questions with a tag is generally considered a no-no. – Sklivvz Mar 17 '14 at 17:34
11

The burn down chart does not display a deadline. It displays your progress towards your team's commitment. I think that is an important note.

If someone is utilizing your sprint to enforce a deadline, then you're not actually doing scrum. You're just working in sprints, which is a very common problem when teams start to adapt scrum.

When the burndown chart represents your burn down of committed tasks, it is more in the hands of your team. If your work is suffering, it's because you have committed to more than you can accomplish. During the next sprint, your team should naturally agree to commit to less work to provide a higher quality product.

| improve this answer | |
  • 3
    I don't think that any true scrum advocate would suggest forcing such a task into a sprint. If it can't be broken down by business value any further, then you can also break it up as you have stated (iteratively). I've also been on teams where this has been solved through variable-length-sprints. A set number of weeks for every sprint does not always make sense. Your sprint is meant to deliver a certain amount of business value. If you need three weeks instead of two weeks to delivery that minimum amount of business value, then so be it. Make that clear in your planning meeting. – BrandonV Mar 17 '14 at 15:28
  • 1
    This is the mantra that is repeated over and over again when I ask this question but you glossed over the fact that, as I said above, some tasks CANNOT be broken up into smaller subtasks, because finding a way to break such a problem up is the problem itself. I think what is implicit in your answer is that in SCRUM you simply don't try to solve problems that are too complex to be solved within the duration of a sprint. This is fine for me, but it should be stated clearly. – Giorgio Mar 17 '14 at 15:37
  • 1
    I don't necessarily agree that variable length sprints imply not doing scrum, although it would be less ideal than fixed length sprints. I think there are two ways in scrum to solve the problem of very large, complex tasks. One is to apply variable length sprints, and the other is to really analyze whether or not you can break up said task in any way. Scrum is also not something to apply globally. It's entirely possible that someone is trying to fit a square peg into a round whole, and other SDLCs should be considered. – BrandonV Mar 17 '14 at 15:49
  • 3
    @Giorgio Can the chunks be tested? Can they indicate some progress towards a measurable goal? So you won't have a fully functional, customer-usable feature after a single sprint... So what? You've already indicated that is impossible. What's the next best thing? Certainly not 'let's cut corners so we can say we met a deadline (by arbitrarily fitting it into one sprint)'. That's not scrum. Instead, do what chunks you can, and validate that the individual pieces work as designed, even if they aren't incorporated into the whole yet. That's what you present at the end of the sprint. – Eric King Mar 17 '14 at 17:08
  • 2
    @Giorgio Sure. A customer will understand "It'll take a month or more to build the whole chair, but in two weeks we'll show you progress towards the first two legs and the back; the rest will come later". What they don't want to hear is "we're not sure how long it's going to take, and we won't have any progress to show you until we're completely done", nor do they want to hear "we couldn't fit the chair you wanted into this arbitrary two-week period, so we built this pseudo-chair for you so we'd have something to show". – Eric King Mar 17 '14 at 17:13
5

What you're describing is a mindset issue more than anything else. Do not think of the burndown chart as measuring progress towards a deadline. Instead, think of it measuring progress towards your estimated goal for this sprint. Instead of your developer thinking "I have XYZ to complete and it needs to be done by the sprint end date", your developer should be thinking "I have XYZ complete and based on the amount of time I have, I should be able to finish it by the sprint end date".

If your chart doesn't burn down 100% it simply means that your estimated goal didn't match what your team was able to produce in the sprint period. It's always beneficial to find out why. Did you not allocate the correct effort during your planning session? Were your developers playing Counterstrike instead of doing their work? Did your team members encounter impediments? Was there a critical bug that pulled key resources away from their work?

These types of discussions should be happening in part during your daily standups, and at the very least should be surfaced in your sprint retrospective. This feedback should be taken into consideration and applied to help improve your estimates in the future.

Fixing quality comes down to your team buying into the notion that there aren't repercussions for having to bump something into the next sprint provided that the reason for it is valid.

| improve this answer | |
  • 1
    There's also unaccounted for tasks that don't go into the project management tool or aren't written down anywhere (babysitting server deployments, fixing 3 bugs that were discovered in order to fix the one bug that's been assigned to you, doing research, creating a prototype, etc.) – Old account Mar 7 '15 at 17:02
5

The way I see it, the purpose of the burn down chart is:

  1. To allow the team to drop sprint commitments early rather than late if won't make it. The idea is that it's better to finish the sprint with one story done rather than two half done, and that the PO would rather know on Monday that this feature won't get done by Friday, rather than discover during the acceptance meeting.
  2. To provide data allowing the team to get better estimates and stabler velocity faster: a good looking burn down chart should means that the team has their act together (not necessarily that they get much done). A chart looking too good usually means it got doctored and is useless.

If the team does anything to make the burn down chart look good, then it defeats the purpose. Remember: the primary measure of progress is working (high quality) software. Not a good looking burn down chart or unrealistic commitments.

If there is outside pressure on the team to that effect, I'd recommend to stop communicating the burn down chart outside the team. It is a valuable tool, but can be corrupt way too easily.

(To be clear: it's normal for overcommitment to happen occasionally. But if it happens regularly, then the team isn't learning: a stable velocity, realistic estimates and good communication about what's a stretch goal and what is promised should keep rough sprints at bay)

| improve this answer | |
4

With software, typically you have the following metrics:

  • Time scale. You have the iteration.
  • Scope. You have fixed the scope.
  • Resources. You have the team members.
  • Quality. Quality has to be 100%

When the pressure is on, which one do you sacrifice? Do you expect the team to create more time scale by working overtime? Do you drop stories? Additional developers probably won't get up to speed quickly enough? or do you just test the basics, and cross your fingers?

What I have seen happen in all the scrum teams I've worked with is that they are under pressure to continually increase 'scope' as its a measure of how good the team is, that to deliver on this, teams over work their hours, and that quality gets squeezed, as developers deliver late, and the end deadline cannot be moved.

What Scrum was intended to deliver was:

Time scale: we review the progress of the product at fixed, periodic occasions which ensure we are delivering features that the customer need.

Resources: We have clarity over who is working in the team for the iteration. developers are not pulled around doing painful context switches.

Quality: We value quality above all. We make sure that everything we produce is properly tested and if we have not tested it 100% then its not yet done.

Scope: We are giving the business visibility over what we expect to deliver at the end of this iteration - based on our past experiences.

In this environment, when the pressure is on, its Scope that's sacrificed.

How to make scrum work?

That is the wrong question. The right question is what kind of output does the company need from the development team? Do they need a quality product? or do they need to release software to a deadline?

When they have come to terms with this, then they will be able to organise the appropriate environment for their developers. Scrum, kanban, XP can all do this, but they are all environment dependent.

| improve this answer | |

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