Greenhopper OnDemand: How to get a long-term iteration view?

[Doug Varn]

I'm coming from Pivotal Tracker. It had a feature I find essential and I'm surprised it either doesn't exist in Greenhopper or is so hard to find that I still haven't done it.

There I could put together my backlog for weeks if not months out in advance and estimate all those stories/epics. The tool would then take my team's average velocity, use that as a guide for the future, and automatically break up the backlog into future iterations. That is, I could see in advance that if my estimates were correct and if the average velocity persisted as it was, my future sprints were laid out before me, and moreso, the dates of each sprint. This way, we could all get a sense for our long-term dates and planning.

Even cooler, I could temporarily adjust the average velocity and the change would ripple through the backlog, say if I knew more or less team members were coming on board, I could up the avg velocity and watch how that would affect the dates.

I don't see anywhere I can get this kind of view. Please tell me what I'm missing.

[Doug Varn · Accepted solution]

The way I've figured out it can be done (more or less) is by:

1. Setting up your sprints in advance via versions (sprint 1 = x.y.z, etc.) and specify dates.

2. Do some configuration so that you see story points on cards and on the right hand column on the planning board. (Don't ask me exactly what I've done, but I've done it)

3. You can specify story point limits to each version (sprint) and drag in stories to each version.

It's not as automatic or easy to see all once as it is in Pivotal, but it will likely get us by.

[Doug Varn]

When things change (priority, product direction, etc.), then the product owner changes the backlog and in Pivotal, the sprints and their associated rough timelines also change as well. It's fully agile.

Points, whatever you associate them with, end up still reflecting the amount of business value the team is able to generate on average per sprint (avg velocity). So it's useful for predicting future timeframes. Pivotal does this automatically and I see no way of getting this view in Greenhopper.

I do see the planning board which shows aggregate info for a particular group of issues. For example, I could create releases for each future sprint and assign epics/stories to those. Then with the planning board, get data based on just the stories for those releases (sprints) but it only seems to show time as days/hours... I cannot assign points to the stories (or see them on the planning board) unless I'm on a rapid board. Hours/days are best to use when splitting up a story into tasks but not as epics or stories. I'd prefer my future be roughly predicted based on backlog estimates in points and my team's average velocity, exactly as Pivotal has done it. It's not fool-proof or meant to provide any "exact date", but at least at all times, you have a rough idea of where you're headed and when if things didn't change. And of course you can show others how changes in the backlog affect future release dates.

[Lee Correll]

I'm confused. How are you estimating how long a task will take? In many agile forms, the purpose of estimating is to provide a frame of reference of difficulty, not a timeframe (check the JIRA "story points") for that. If you're estimating timeframes that far out, that doesn't sound like an Agile methodology to me, that sounds very waterfall-ish. What do you do when the client changes direction, priority, or introduces a new concept?

[Doug Varn]

When things change (priority, product direction, etc.), then the product owner changes the backlog and in Pivotal, the sprints and their associated rough timelines also change as well. It's fully agile.

Points, whatever you associate them with, end up reflecting the amount of business value the team is able to generate on average per sprint (avg velocity). So it's useful for predicting future timeframes. Pivotal does this automatically and I see no way of getting this view in Greenhopper.

I do see the planning board which shows aggregate info for a particular group of issues. For example, I could create releases for each future sprint and assign epics/stories to those. Then with the planning board, get data based on just the stories for those releases (sprints) but it only seems to show time as days/hours... I cannot assign points to the stories (or see them on the planning board) unless I'm on a rapid board.

Hours/days are best to use when splitting up a story into tasks but not as epics or stories. I'd prefer my future be roughly predicted based on backlog estimates in points and my team's average velocity, exactly as Pivotal has done it. It's not fool-proof or meant to provide any "exact date", but at least at all times, you have a rough idea of where you're headed and when if things didn't change. And of course you can show others how changes in the backlog affect future release dates.

[Doug Varn]

Atlassian support has made it clear, there is no way currently to view your backlog as forecasted sprints like Pivotal Tracker does it. :(

How do others get around this? If you create a huge backlog for your entire roadmap in Greenhopper, how do you have any idea when things will be complete?

[Doug Varn]

Atlassian support has made it clear, there is no way currently to view your backlog as forecasted sprints like Pivotal Tracker does it. :(

How do others get around this? If you create a huge backlog for your entire roadmap in Greenhopper, how do you have any idea when things will be complete?