Creating a release burn down chart for forecasting

Question

I have been asked by senior management to create a roadmap:

Being pressured into doing a Gantt chart

Some contributors have recommended that I create a release burn down chart.

Questions

• If I have epics that are not broken up into stories yet, how do I add them in the release burn down chart
• If I stories where the team does not have the knowledge yet to compete the story, how many points do we give them?
• Who assigns points to the story? Me or the team? How can I/they assign points if they do not yet have the skills to complete the work?

Thanks

Answer 1

I believe some project management software which supports burndown charts can help you. As I'm working as a support specialist for Eylean Board I can answer your question in the context of our software.

For instance, in Eylean you can have two or more levels of tasks (based on a parent-child hierarchy principle). You can use parent tasks as epics and child tasks as stories. Then you can simply choose whether to include child tasks in reports or not. If you prefer the latter then in your burndown chart you will see only epics. Below I have attached a couple of screenshots to help you understand what do I mean:

Talking about estimation itself, I believe that you should decide that with your team. Scrum says that you should estimate stories during the Sprint planning and the team as a whole is responsible for that. Anyway, wheter you decide to estimate at the begining and re-estimate during the project, In Eylean you will be able to do that without any worries as well.

Let me know if you need an additional explanation on this subject.

Answer 2

If I have epics that are not broken up into stories yet, how do I add them in the release burn down chart

If you want to do a release burn down that includes the epics then you will need to estimate the number of story points in the epic. It is up to you and the team to decide how much effort you will put in to this. For example, the team could take a look at the epic and say it is roughly 30 story points. Or they could decompose the epic in to stories and go through estimating each story in turn.

If I stories where the team does not have the knowledge yet to compete the story, how many points do we give them?

Again, you have a number of different approaches. The team could simply guess the number of story points. Alternatively, they could spend some time investigating the story so that they have sufficient knowledge to do a more reliable estimate.

Who assigns points to the story? Me or the team? How can I/they assign points if they do not yet have the skills to complete the work?

Typically in Scrum estimates are done by the people doing the work. Identify who will be doing the work and ask them to provide estimates.

These answers may well make you feel uncomfortable. This is to be expected as a release burn down is attempting to predict something that has inherent uncertainty. This is one of the reasons why the release burn down is no longer a part of the Scrum Guide.

Personally I think that a release burn down becomes less useful the longer the period it is trying to predict. If a team is planning a release in 2-3 sprints it can be quite accurate. If the team is planning a release that is 4-5 sprints then there is a larger margin of uncertainty. I struggle to see the value in using a burn down for 5+ sprints.

The intention with Scrum is that the team will respond to change during the course of development. A long term prediction is unlikely to be accurate if this is happening. I would argue that it is better to minimise the time you invest in estimating stories and epics that are a long way down your product backlog. Why spend a lot of time when there is little if any benefit to be gained?

Answer 3

As the target of what to include in a release is not fixed, I generally prefer to create a release burn-up chart, rather than a burn-down chart.

A release burn-up chart shows on the horizontal axis the sprints and on the vertical axis the story points that have been completed/estimated. It also has (at least) two lines on it:

1. A line representing all the work considered for the release, with a projection into the future assuming the total amount of work remains stable
2. A line representing the work that the team has completed so far, with a projection into the future of how much work the team can complete based on the average velocity. If you want to be really fancy, you could add a cone of uncertainty around this projection to indicate that variations in velocity have an impact on the projected release date.

After each sprint, you would update the chart with the most recent values for the total size of the backlog and the porting that the team has completed. If you do this for a longer period of time, you will see that the total size of the backlog will fluctuate, because features get added/removed and story estimates get revisited. This is entirely normal and should be valuable information to your project-manager.

---

To answer your specific questions:

If I have epics that are not broken up into stories yet, how do I add them in the release burn down chart

If the epic isn't broken into stories yet, then you should estimate the epic as a whole. The uncertainty on the estimation will be bigger, but that is not a problem. When you get around to breaking down the epic, the estimates have to be revisited anyway.

If I stories where the team does not have the knowledge yet to compete the story, how many points do we give them? Who assigns points to the story? Me or the team? How can I/they assign points if they do not yet have the skills to complete the work?

The best estimates come from the people who will do the work. This holds even if they don't yet have all the knowledge yet to actually do the work. The only thing is that the estimates will generally be more conservative (i.e. higher) because a larger risk-buffer gets included due to uncertainty.

You shouldn't spend too much effort in getting the estimates for stories/epics far in the future to be accurate. One rule to keep in mind is that estimates can always be revisited/changed in Scrum. Only after you have taken a story into a sprint should the estimate be considered to be fixed/final.

Answer 4

Agile Planning is continuously done from vision level to daily level. Product Manager, the representative of the customer, in consultation with the sponsor prepare product backlog and try to prioritize the product backlog based on the estimation done with the help of all stakeholders, team members and others.

Estimation could be done with story points or ideal days. When the total number of story points for the entire product backlog is divided by the velocity of the team you will be getting the number of releases that can be made.

User stories are written on a card (front and back). Extensive documentation is replaced by face-to-face conversation among the team members. Doubts are cleared and the story is confirmed with definition of done. Agile recommends that the good user story must conform to INVEST principles - Independent, Negotiable, Valuable, Estimatable, Small and Testable. Using planning poker you size your stories with points 1,2,3,5,8,13,20,40. If the size of your user story exceeds the size of 40 points then it may be called as Epic. So the epic must be broken down to small independent stories. You can gather the related user stories and named it as Theme. Scrum deals with small small user stories and themes which would be sufficient to process within 2 weeks or 4 weeks sprint/iteration.

The size estimation of user stories enables you to find out the velocity of the team. However, it is not fixed. The velocity is the number of story points the particular team is capable of completing within 2 week or 4 week iterations. It may increase or decrease over a period of time. Total number of story points to velocity of the team gives you the no.of releases.

During sprint planning the team picks up prioritized backlog items from the product backlog and include them in sprint backlog (the items to be developed in each iteration). Release planning is a high level planning at product level and sprint planning is sprint level planning. At the end of each iteration Minimum Marketable Feature is delivered.