What is the migration path to the Rapid Board (from Time Tracking to Story Points)?

[Björn Wennerström]

The GH 5.9 Labs updates to the Rapid Board look really promising, it could finally end the pain of using the utterly sluggish Planning Board, and of course enable multiple project planning and burndown charts. But how to get there?

To us the only meaningful burndown chart in GH has so far has been the "Hour Burndown Charts", based on the Remaining Estimate field (part of the Time Tracking package in JIRA). This is what Atlassian has implicitly recommended. Thus, we have used Time Tracking for Scrum: we've set the story points in the Original Estimate field in our planning poker sessions and we've updated the Remaing Estimates during the sprints. In the sprint planning sessions we have used the "Version" view of the Planning Board and drag-n-dropped issues into the next fixVersion until the Time Estimate statistic adds up to the sprint velocity. Using Time Tracking (as opposed to the Story Points field) has also allowed us to set individual estimates on sub-tasks and get them automatically summed up to the parent issue.

But the new Rapid Board changes all that:

• The Rapid Board "Report" burndown chart is not configurable to show remaining estimates, only fully burned down story points for closed issues. This is unfortunate as it makes it pretty much useless for us and is discussed in another thread.
• The Rapid Board "Plan" view is hard coded to use story points stored in the Story Points field. Will Atlassian offer migration of Original Estimate in Time Tracking to Story Points?
• Story points are not automatically summed up from sub-tasks to stories in the Rapid Board "Plan" view. While unfortunate, we could possibly accept this and in the future only do estimates on the top level stories.
• Releases cannot be planned in the Rapid Board. This adds an unnecessary step for us as sprints are the same as release, but this is also discussed in another thread. An option for us would be to use Sprint instead of fixVersion. Will Atlassian offer migration of earlier fixVersion releases to Sprints?
• There is no view in GH to see contents of previous sprints, custom JIRA filters or Confluence pages have to be made for that purpose.

[Björn Wennerström · Accepted solution]

Using the Rapid Board for planning will mean for us sacrificing the aggregation of estimates in sub-tasks and rendering the burndown chart almost useless. But it's probably worth it to get multi-project planning.

Our migration will consist of:

• Farewell ceremony for the burndown chart.
• Running a custom script to move Original Estimate to Story Points.
• Disable time tracking to remove confusion as to where estimates go.
• Manual process to create releases after every sprint (JIRA bulk operation). Since Sprints are stored as global enum we can't use them instead of fixVersions even in single project sprints (the sprint ID stored on JIRA issues won't correspond to the sprint name).

[sclowes]

Hi Björn,

We're currently working very hard on the Rapid Board and releasing significant new features every two weeks. We're concentrating on making a great Scrum planning experience from the ground up.

• In 5.9.3 which will was released today we have added a Sprint report that can be used to show previous sprints. We're still working on enhancing it

• The idea of burning down partial story points is highly debatable (I'm aware that some people find the idea very amenable and that Jeff Sutherland and Scott Maxell have recommended it). For many, just achieving reliable velocity from Sprint to Sprint with a traditional Product Backlog Item (PBI) estimation in Story Points is a challenge enough. Using partial Story Points to measure in Sprint progress in the way they propose is potentially powerful, but most users are more familiar with either full Story burndown (which is the only measure of user deliverable value) or hour burndown. As a result we're not 100% sure what we will implement here but it's most likely to be a burndown of Remaining Estimate

• While remaining estimate is traditionally a time value it can technically be used for any value you wish. That is, '1 h' can be considered to be '1 story point' in your environment. In that scenario you could use any potential burndown we offered on remaining estimate

• More traditional Scrum teams use two levels of estimation, one for velocity and predictability that estimates PBIs, then one for tracking within the current Sprint that estimates tasks (often in hours). In this scenario we would need two separate fields to achieve the rollup of estimates you desire

• As you note we have separated Sprints from Versions (i.e. fixVersion). At this stage we don't intend to offer a migration path as previous Sprints can continue to be viewed as versions in the Chart Board

• Regarding release planning, as I commented in the thread you mention providing an oversimplified mapping of releases to Sprints will end up satisfying only the simplest case. We do hope to address the general problem of release planning in the future

Thanks,
Shaun

[Björn Wennerström]

Thanks for your quick reply!

Separating story points and estimates has never made any sense to me - assessing story points and setting an original estimate is conceptually the same thing and I don't see why the information should be duplicated. But I have heard this view elsewhere and I won't push my case any further. Considering your view on this I conclude that you won't be offering migration of Original Estimates to Story Points.

[Erwin Saegesser]

Hi Shaun -

Sorry for not being clear enough. We basically have the same issue as Björn stated above: "To us the only meaningful burndown chart in GH has so far has been the "Hour Burndown Charts", based on the Remaining Estimate field (part of the Time Tracking package in JIRA)."

To your point about: I'm afraid I don't really understand how you're ahcieving this today or what your final objective is. The hour burndown in the classic boards will not show both story points and hours at once.

Clarification: We don't show both at once (as you said, not possible). However, we plan stories in points, then break them down in subtask and estimate those in hours. During the sprint we control the progress with the burndown based on remaining hours.

Your workaround is worth a try. I just cannot understand why you don't just add the "Hour Burndown Chart" to the available reports (in general you guys do such a great job!).

Regards,
Erwin

[sclowes]

Ok, it sounds like we're just miscommunication then. If you switch time tracking on the burndown will then show remaining hours, I.e there is an hour burndown chart today. A board with Story Points as the estimation unit and time tracking on will show Story Points in the velocity chart but hours in the burndown. Thanks, Shaun

[Lucas Nelson]

Shaun,

The problem we've found in my team with that solution is that the "hours" in the burn down change as the team resolve the sub-tasks. The burndown only catches up when the story is completed and resolved, then the burndown suddenly drops like a cliff by the total hours in the Story, instead of the real view where we can see the team progress day-by-day. The other impact is it constantly looks like the team is behind the curve with the burndown until right near the end of the sprint when everthing catches up all of a sudden. Makes it hard to manage the project, especially with relatively small teams - 2 or 3 people - and 2 week sprints. The burndown charts look like a bad joke.

Same thing happens when using the Story Point tracking method (although it's by design there since there's no expectation to be able to burndown a Story point by point.

We're still stuck using the Classic Board because of this.

Please, please, please reconsider supporting those customers who choose to use sub-tasks, and do estimates in hours, and want to track the real progress of the team day-by-day.

Lucas.

[sclowes]

Hi Lucas,

Can you provide more detail? If you have configured your board for 'Time Tracking' then the burndown will burn hours as they are logged against stories or sub tasks, the burndown will not move when the stories/sub tasks are moved to the last column.

Thanks,
Shaun

[Lucas Nelson]

hmm okay. Let me ensure we are on the latest version of Jira and GreenHopper first and I'll try it again. Will report back with more detail, screenshots etc. when I can reproduce (or to report it's working now).

Thanks for the response!

[Lucas Nelson]

Shaun, I've tried again on a more recent version of the Rapid board, and the burndown chart is looking much better! It is burning down the sub task work as it's done. This is different to the last time I saw it, sorry.

The one remaining niggle I have is in the planning stage you can't see the summed-up estimate against the story in the "Plan" phase until you start dragging the sprint marker down. It's not a big deal.

Thanks for the quick response above.

[Erwin Saegesser]

Got it. Perfect!

Thx,
Erwin

[Erwin Saegesser]

Hi -

we have no plans to give up the "Hour Burndown Chart" (Points for Stories, Hours for Technical Tasks and Bugs).

We're on Jira/Greenhopper on Demand. When can we expect a resolution: a) "Hour Burnddown Chart" or b) custom reports in the board?

Thx in advance,
Erwin

[sclowes]

I'm afraid I don't really understand how you're ahcieving this today or what your final objective is. The hour burndown in the classic boards will not show both story points and hours at once.

If you're happy to plot them separately you can just have two separate boards with the same filter. Set one up for estimation in story points with no time tracking (which will give you the story point burndown you're asking for) and the other up for estimation in original time estimate with time tracking on (which will give you the hour burndown). Note that you do not need to maintain the two boards separately, since they have the same filter they'll see the same issues and sprints.

Thanks,
Shaun

[Serge Prud'homme]

Our team is more comfortable with estimating stories by breaking them down into sub-tasks during the sprint planning meeting and then estimate the effort required for each sub-task (in days, not story points).

Yes, purists might not agree of not making that separation between story points and sub-tasks estimates.

For this to work we would need the Rapid Board sprint marker to show summed estimates of all the subtasks associated with the selected stories.

I saw that in Greenhopper 5.9.7.3, it is possible to estimate the user stories in time instead of story points. That's great. What about the above?

[sclowes]

Hi Serge,

In GreenHopper 5.9.8 (which will be released shortly) you can configure GreenHopper to use time tracking on tasks for the burndown. We do not currently sum the estimate of tasks and show it in the marker because most teams use their velocity in their estimate statistic (e.g. Story Points, Original Time Estimate) to understand how much work they can get done in coming Sprints. Using the task level estimates means that the Sprint marker cannot be used to estimate the amount of time the backlog will take to be delivered (because many stories will not have been broken down in to tasks).

Thanks,
Shaun

[Danut Manda]

Hi Shaun,

We are in the process of adopting Scrum and implementing the workflows in JIRA & GreenHopper. We encounter the same problem with the sum of estimated hours in the Plan mode of the rapid board. Here is how we plan to use GreenHopper.

When a story is added to the backlog, the team first estimates it in Story Points (by setting a value in the Story Points field) – this serves as a rough estimation. At this moment the story in question has nothing set at Original Time Estimate. This is made via the classic Plan Board – which we find it very interesting because it is a great tool for the ProductOwner for planning the releases.

During the sprint planning meeting, the stories are split into sub-tasks and we estimate the effort required for each sub-task in hours (not Story Points!) by setting the time estimate in the Original Time Estimate field of each sub-task. At this moment the stories still have nothing set at Original Time Estimate (the time is only set on the sub-tasks). The commitments and sprint marker are made by Original Time Estimate (not by Story Points). We have Estimation Statistic set on Original Time Estimate.

In our opinion this practice is what Jeff Shutterland suggests in his Scrum handbook.

But because the GreenHopper does not make the sum of the sub-tasks estimates, the stories appears with no time estimate and we are unable to make planning!

In addition, if you open the story in its own form, the time aggregation is made. So there is an inconsistency here!

For us, not having the sum of sub-tasks estimates in Plan mode is a buggy behavior. We really need this to be fixed! And it is obviously that I’m not the only one that wants this functionality.

Thanks,

Danut

[Renjith Pillai]

@Björn : Frankly, the story point estimate at the Story level actually has not relation to the efforts estimated for the sub-tasks. In that sense, aggregation of estimate from Sub tasks to story is a bit of deviation.

And I guess it is too early to conclude as the GH team indeed has to consider all the points that you mentioned.