1

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

|improve this question
  • "One question per post" is a guiding principle on this site. Please decompose your post into the one question, one post format to allow for canonical answers to focused questions. – Todd A. Jacobs♦ May 17 '16 at 13:31
  • @CodeGnome this really is a single question that boils down to "How do I produce a feature/epic level burn down?" – RubberDuck May 17 '16 at 13:59
  • @CodeGnome original question was about gaant charts. – bobo2000 May 17 '16 at 14:06
2

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: enter image description here

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.

|improve this answer
  • That's the best advertisement i have ever seen. – Alexander Averchenko May 17 '16 at 14:11
  • 1
    I prefer to call my answer "help with reference to a solution". We just have a right tool which I strongly believe covers a lot of both new and experienced Agile user's concerns. So I do not have any intention to hide that I'm a part of Eylean team :) – Evaldas Bieliūnas May 17 '16 at 15:19
  • 1) it's been long established that's it's okay to reference your product so long as the answer is a legitimate answer. 2. This is a legitimate answer. 3. Most burn down charts are generated based on story points or estimated hours. In Scrum, stories aren't estimated until just before they're implemented. How do you produce a burn down for epics with stories that haven't been estimated yet? Answer that, and you might get my upvote. – RubberDuck May 17 '16 at 15:47
  • It's a tough question if you rely on pure Scrum approach. Again, from the Eylean perspective, there are 3 types of burndown reports available: by estimation (hours), by complexity (story points) and by task. The latter option uses overall task count and their migration data to increase or decrease amount of work remaining. Here is how it looks like: s32.postimg.org/6w7eqnts5/Burndown_by_task.png – Evaldas Bieliūnas May 18 '16 at 8:25
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?

|improve this answer
  • My boss is currently insistent that I show him a visual product roadmap to give a forecast of what we will be doing over the next 6 months. Currently I am planning weekly and he doesn't like that. – bobo2000 May 18 '16 at 8:46
  • 1
    6 months is a long time in development! If your boss accepts that you are using the Agile approach then you would expect to have significant change during that time. When you show progress to your stakeholders you would expect to receive feedback that might change what you plan to do. I think it would be unrealistic to do a detailed release burn down for 6 months. So perhaps just do some light estimating instead. Don't waste too much time on it. – Barnaby Golden May 18 '16 at 9:25
  • 3
    If I were you I would get the team in a room and spend a maximum of 20 minutes going through the backlog putting very rough estimates on everything. Then do a simple diagram based on those estimates. When you give the diagram to your boss caution him that you may well need to update it every few weeks as it is likely to quickly become out-of-date. The key is to not spend too much time on it when you could be spending that time doing something valuable! – Barnaby Golden May 18 '16 at 11:09
  • 1
    I would ask him why he needs the stories for an epic that the team may never never implement @bobo2000. It sounds like your boss wants to continue to do waterfall development with a new name. – RubberDuck May 18 '16 at 11:44
  • 1
    Don't give up @bobo2000. Have lots of open and honest conversations. Learn and educate. Ask hard questions. Fail fast and iterate to success, both with your development and your transformation. Good luck mate. – RubberDuck May 18 '16 at 13:38
0

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.

|improve this answer
-2

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.

|improve this answer
  • This doesn't answer the question. OP wasn't asking for a synopsis of common Scrum practices. – RubberDuck May 18 '16 at 11:38

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.