0

In the company I work we use scrum.

Unfortunately, We do not track items work remaining, but instead we use "due dates" mode per item.

My question is, Is it possible to create a burn down chart according to due dates?

From my previous experience in scrum, I had used burn-down chart after updating items work remaining on a daily basis, and I can't seem to think of a way to implement it while in due dates mode.

Any guidance would be appreciated.

  • 1
    If you are using due dates instead of effort remaining I guess you are not inline with scum guidelines and the fundamentals of scum. So I would say you are not running a project with scum, simply. So you can't talk about burn downs. – Nuwan Perera Mar 16 '15 at 12:25
  • With due dates, it will be difficult to come up with burn downs. There is extent you can customize the methodology. So the problem is if the fundamentals are broken, simply your question becomes invalid. How ever, you can do a simple trick to get the remaining from due date. If you know the due date for a task you can calculate the hours required to complete the task multiplying by the hours a resource will work on that said task. There you will get the hours remaining and still can draw your burn downs. – Nuwan Perera Mar 16 '15 at 12:59
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. – Marv Mills Mar 16 '15 at 13:32
7

Assuming due dates are per-item, then no, there's no math that would translate that into a sum of known quantities that could be burned down to zero over the course of a sprint. You could burn down items remaining, and any item that misses its due date doesn't burn down, but this is hard on the team and dangerous to the project. Once an item misses its due date, the team will have no motivation to continue working on it and will move to other tasks they can still get credit for completing on time.

You could perhaps hijack the estimated time vs actual time burn-down model, where estimated time is the number of days from the start of the sprint until that due date. This keeps the tracked value on the item 'alive' and prevents the deprioritization above.

I'm a little concerned, though, that you're breaking a fundamental principle of scrum: the only due date is the end of the sprint. The team takes on a stack of work at the start of a sprint and promises to have it completed by the end. If due dates are a problem, assign work to sprints that end before those dates. Use one-week sprints if work is coming in so rapidly that you need to make sure it gets into a sprint early enough. If even that isn't rapid enough, then maybe scrum isn't for you, and you should stop doing it. Jamming scrum into that kind of environment leads to failure all too easily.

Perhaps look into pure pull-based kanban, and put the nearest-due date items at the top of the pile. The trick is to get into a position where due dates aren't at the front of your mind. If you're always racing to meet them, something is wrong, and charts won't fix it.

Lastly, I'd recommend getting your management together to talk about the state of scrum at your company. Either they aren't really doing scrum and think they are, or the team you're on has a broken implementation and needs to be corrected by others at the company who know better. Hopefully it's just the latter, because if it's the former, hoo boy. Nothing spells doomed quite like a company that thinks it can pick and choose the parts of scrum it likes and leave out the rest. Remember: frankenscrum and waterscrum aren't real. They're just myths agile coaches made up to calm managers down while they subvert them from the ground up. You aren't supposed to actually do them!

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.