How do you organize / plan your Product Backlog and Sprint Backlog ?

JIRA Autobot February 2, 2012


I would like to know how others organize their Product Backlog and Sprint Backlog in Greenhopper. I have couple of quesitons :

1. Do you create a version called Product Backlog and then have all your User Stories / Epics there ?
2. Do you then rank the User Stories / Epics in that version ?
3. Do you estimate your US (User Stories) in points ?
4. When you plan an Sprint do you then create a version like Sprint 1 then create tasks that relates to an US ?
5. If you create new tasks how do you relate those to the US ?
6. Going to an course held by Mike Cohn regarding SCRUM he said that Product Backlog should be estimated in Points and tasks that are part of an Sprint is estimated in ideal hours / days. Do you do that ?
7. If one does as 6 then how dou you keep your Release burndown chart (looking at User Stories) updated since developers are working on Tasks and they are estimated in hours / days. In the course i learned that at the end of the Sprint one should update the Release burndown chart but since User Stories and Tasks are decoupled this must be done manually or ?

What i do currently is that i have an backlog of both tasks and User Stories in one place (Version in Greenhopper) and i find that a mess. I then take from that list and move into Sprints which again are Versions in Greenhopper. The problem is that i don't have the overview of the release or how the overall status is.

I hope some of you have some experience which you can share with me.


4 answers

1 accepted

3 votes
Answer accepted
Andre Brissette February 14, 2012

Hi donnib,

what you are describing here is a standard Scrum process. I'm using it with Greenhopper for years now and it works perfectly. I'm not sure but I think your problem is that your are using "Task" instead of "Sub-Task" on Story. Also be sure you are using the Scrum template. To verify, check in the upper right menu Tools/Configuration of Greenhopper and be sure that Project Template: is set to "Scrum".

Using Sub-Task on Story is the way to do when using Scrum with Greenhopper. You put Story Point on Story and Hours on technical task(Sub-Task). When everything is setup correctly, you will see that the tool behaves pretty much like you would expect form a "Scrum Wall". For example, when looking at the a Sprint in the Task Board, all Sub-Task will automaticaly be displayed under their respective parent Story and you will be able to move then one by one from To DO, to In Progress and Done. When all task of a Story are Done, you can then then change to status of the Story with a click on the status of the Story at the right end of the line. "Cards" is my prefered views on the task board, you can set it in the top right "Views".

Greenhopper is naturally designed to work in this configuration. For example, one of the advantage is that in the Planning Board the Story card will automatically compute the total of time of Sub-Tasks. So you will end up with something like this:

Scrum with Subtask

In this example, I did not set hours on the Story PJC-171; "1 day, 5 hours" is the sum of hours of related Sub-Tasks. What I had manually enter in the Story is only the 3 Story Point in the bottom right corner.

Regarding your question #1, it is a matter of taste. Some people create a version named "Backlog" other people use the default "Unscheduled" version as their backlog. For my part, I prefer to create a new version with name Backlog. I only use the Unscheduled to temporary store item to be dispatch. Doing so I know that Backlog always contain things already prioritized and I force myself to keep Unscheduled empty as much as possible. Regarding Release and Sprint, one element is very important and it is to use the version hierarchy feature. For example, lets say you have a Release called "February" and it contains few Sprint like "Iteration 12", "Iteration 13", ...etc, be sure to set the "Parent:" field of you Sprint with the corresponding release. When it's done, in the Planning Board on the right you should see something like this:

Release with its Sprints

With this setup, I think most of your other problems should be solved.

Hope it help,


JIRA Autobot February 14, 2012

It sure does help, ! Thank you for that. First of all we are not using SCRUM template so we have alot of other type of issues but i can see that we should stick to the right template and use only Story, Epic and Sub-task issue types. We have not started to estimate the Stories in Story points. I can see you use that. Can you get an burndown chart of the release which is measured in story points ?

1 vote
Andre Brissette February 14, 2012

Of course you can, just go in the "Chart Board" menu at the top Greenhopper. For current Release you probably would use:

Chart Board / ReleaseName / Statistics Burndown Chart / Story Points

To see the velocity of your previous Release, you can look in the "Released Board" menu.

Release Board / ReleaseName / Statistics Burndown Chart / Story Points/ By Children

Another advice, try to keep "Epic" in your Backlog and only move related Story in Sprint. This way you keep your "Task Board" clean and it should be that way in Scrum anyway. If you haven't broke down Epic in its Stories, it means you're not ready to work on it.

0 votes
aabbb February 14, 2012

Got it thanks.

Now i am just waiting for Atlassian to implement an better support for SCRUM in the Rapid board since they have implemented Sprints but one cannot see burn-down charts of Sprints as of now.

0 votes
JIRA Autobot February 8, 2012

No comments or ideas ??

Suggest an answer

Log in or Sign up to answer