How to compute scrum burndown chart when projects overlap?

Question

In my team we have a multiple projects, some short term and some long term. The team is required to deliver these projects on different dates and the effort to deliver these is run in parallel with the team working on stories for more than one project during each sprint.

When trying to compute our burndown we aren't sure what to do.

As the team is split between projects the velocity can change dramatically week-on-week as people shuffle to the tasks best suited for their specialty across the projects. This makes it difficult to create a reliable and meaningful burndown chart for each project.

However if we combine the stories into a single burndown chart how can we track against the release if the release dates are different and it isn't obvious which points remain for each project.

Is there a good method for dealing with this?

Answer 1

When a SCRUM team works on stories from multiple projects, you should have several burn-down charts:

• One chart indicating the progress on the stories within the current sprint. This chart is updated daily by the team to indicate how they are progressing to the sprint-goal of that sprint. Where the stories on the chart come from should not matter for the chart.
• One chart per project to keep track of how the project is progressing towards its release date. This chart is mainly for the project manager(s) to keep track of the progress of their project(s) and should be updated only when a story for that project is delivered by the team.

---

The velocity measurement is SCRUM is meant to give the team a measure for how consistent they are estimating the amount of work/complexity that they can handle in a sprint. This can only work if there is a single golden standard to use as a reference for a unit of work/complexity.
The golden standard can (and will) differ between teams, but it should be consistent within a team, even if that team works on stories from different projects.

The recommended way to establish such a golden standard is to pick a story of medium effort and give that 3 story points. Then you estimate all other stories relative to that golden standard.

Answer 2

Burndown charts are used to estimate the amount of effort(points) remaining for a release. Sometimes, this can be projected to get a rough approximation of the release date based on delivery.

If your goal is to purely to track story points (not release date), then most tools allow you to create features or sub-groups within a master project, and then get story point charts for each feature separately. This helps you keep track of the flow of stories in each feature.

However, if you are trying to track on-time delivery against a release date, your workflow renders it somewhat meaningless. Consider, your team puts in a different number of hours every week for any particular project. If you do not know how much effort you can put in for each week in the future, how will you even calculate when all the tasks will end?

That said, I do have a few suggestions. You can try to "approximate" a standard velocity for each individual project. Actively change your team's prioritization so that the team "as a whole" outputs some standard velocity per project. Individuals would still vary as per their expertise in specific projects.

You would be doing this anyway to make sure that no project falls behind. Just formalize that process and then use this velocity to track your on-time metrics.

Answer 3

Story points are a relative value. How much work is this story, compared to another one? Once you have reference, you should be able to estimate all stories regardless of the project they are for. It might be that a similar task in one project is always more work than in the other - but you can still compare the amount of work to your reference point.

The speed in storypoints per sprint should then then depend on the team, not on the project they work for.

You can then make estimates: This work for project 1 will be done if project 1 gets full priority. If we pull in these stories from project 2, then this much will get done.