GreenHopper (Scrum): Child-versions vs Sprints? How do you plan your sprints?

[Prem Mariappan]

Hi,

Before starting using the GreenHopper Scrum Rapid Board, I was using sub/child-versions for sprint planning. Now the Scrum Rapid board seems to be the most intuitive & proper place to do so.

How do you do your sprint planning?

I guess with the Scrum Rapid Board it is easier to do it the proper way. Versions are for product versions. And Sprints are for sprints. It will be good when GH is able to deal with the planning of multiple sprints - it's nice to be able to see what's in the pipeline.

Thanks,
Prem.

[Beth Schaefermann · Accepted solution]

Prem,

I'm of the school that there is no "proper" way for using versions, mostly because no two projects or project managers are alike, even if they're both certified Scrum Masters or Prince 2 Die-hards, what-have-you; but, I do think there is high value in talking to people and asking, "How do you do it?"

It sounds like my team operates similarly to yours, although I've seen people use versions as tracks of work, sprints/ iterations, shut-down or holiday gap place-holders, etcetera. Versions, to me, are time containers that map to a theme. We do currently child sprints/ iteration versions to release versions. We also track against epics.

We rarely, if ever, use the task board. We use the rapid board mostly due to that we can map swim-lanes on top of what more-or-less translates to a taskboard. We also have intra-team, cross-geo representation so we have set up the rapid board to turn some teams on and off in order to focus portions of our daily stand-up convos.

I am curious about how you are now using the Scrum Rapid board to define versions differently from the way you were doing so before. What changed for you? We're using JIRA 4.4 and are in the process of upgrading to 5.0.3; I am not sure if there is a change there that alters this experience.

[Prem Mariappan]

Prior to using the Scrum Rapid board, we were using child versions to plan sprints. Typically a project may last only 1 - 4 sprints for the majority of projects. And usually a single major release version, before a project is complete and enters maintenance mode.

Now we are using the rapid board to plant sprints. (Wish we could look ahead to plan multiple sprints though.) And the is now being used Planning Board is used to group issues into release versions (if the project requires more than 1 version)

Fair point about no 'proper' way of using versions. We've had to adapt and streamline our usage of the Scrum methodology and of Jira/Greenhopper to suit our requirements - many fast turnover projects by a small team. We want to spend most of our time developing, not administering/managing the projects!

So far we're liking it very much and looking forward to the direction GH is moving.