Intersection of GreenHopper Sprints and Project Fix Versions

[Andre Bickford]

I'm really confused on how we're supposed to be using the Planning Board with respect to JIRA Fix Versions. We set a Fix Version for an issue we know we plan on doing sometime down the road. If our current version is 2.1.1, we might set a Fix Version on an issue for 2.1.2 if we know we'll be doing the work in that future version. This is basic stuff, and it's how we plan our roadmap. I assume most companies that use JIRA do the same thing.

However, when I want to plan a sprint with GreenHopper I essentially have to redo the work of planning the work by finding the issues in the next unreleased Fix Version (say 2.1.2 from our example above) and drag them into the next sprint. This isn't too bad to do it once, but when issues are being added / removed from Fix Versions daily doing the duplicate work to maintain the GreenHopper sprints is very tedious.

I assume I'm not using the product correctly and the problem is with me, but I just can't grok how Atlassian intends us to use these two disparate methods for planning future work. Can someone clarify?

[sclowes · Accepted solution]

The easiest way is to just use Scrum practices, that is, don't mark issues for when they will done (because plans will always change), just rank them in to the order you'd like them to be completed. Then, when you start a sprint and know that those issues will make it in to the version you plan on releasing, just go the Sprint Report, click View in Issue Navigator then bulk edit the issues to assign them all to a fix version.

Thanks,
Shaun

[Michael Brinkman]

Thanks for replying to all of these questions, Shaun. I'm tracking them down across the forum here and it strikes me that it seems as though this isn't considered a big deal by the GH team. i.e. having a manal and potentially error prone step that has to happen in order utilize all of JIRA's built in support for versions.

Here's an example of where I find this workarond problematic: Imagine that a bug is discovered while testing a story for a sprint that was clearly introduced by other work in the sprint. In our case, we add those to the current sprint so that we can triage the bug debt at the end of the sprint and either prioitize the bugs on the backlog or plan to address them as part of the next sprint in favor of other backlog items. That also allows us to better understand our defect arrival rate as we develop code. But if we add the issue after we do the initial bulk update you mentioned above, that bug won't be tracked as filed and fixed for that release. It's just orphaned from a version perspective and so we can't report on our overall performance in delivering the final version accurately.

GH is a great tool, but this is a significant functional gap and if nothing else, it's going to cause me to have several teams do more manual updates of issues to get the reporting we want to use to feed back into our process improvement loop. There has to be a simple way that this kind of association can be made once and then automatically inherited.

Thanks!

[sclowes]

Hi Michael,

Your example is exactly why we would recommend applying the fix version (via bulk update) at the end of the sprint (not the start). At that point you know exactly what will go in to the version. Consider the alternative (and very common) option in your scenario where some of those bugs found do not get fixed before the release, you might like to set the 'Affects Version' field but you definitely won't want to se the 'Fix Version' field because the bugs aren't fixed.

We do consider release planning important, but it's not simply a case of making a sprint a version, it's surprisingly rare that sprints truly map 1 to 1 to released versions. We've been looking at designs for improved release planning and we plan to deliver something in the future.

Thanks,
Shaun

[Michael Brinkman]

Just to finish that last thought... In a perfect world I would like to be able to define a context that includes any issue field which my users can select and which will then pre-populate those fields (labels/fix versions) based on the selected context's attribtes.

Thanks for the discussion!

[Michael Brinkman]

Hey, Shaun. In our model, a fix version represents an intent and the status indicates whether that intent was achieved. Also our default intent is to fix a bug introduced during a release as part of that same release cycle. We then scrub them out to our backlog or schedule them for a subsequent iteration depending on what tradeoffs we want to make vs other backlog items targeted for a release. You could think of this as the bugs being opted-in by default.

I'm afriad, though, that you're misunderstanding me due to a failure on my part to clearly articulate what I'm looking for: I don't need a 1-1 relationship from a sprint to a version. It's actually not that common for us to have a team working across versions, but it does happen and as I stated in my other comment I understand there's value in supporting that use case. What I need is some way for anyone testing a version in development to have their issue associated with that version. I would prefer using the fix version field but I could easily adapt to using the affects version field.

What I'm concerned about being able to look at my issues along the version dimension instead of the execution (sprint) dimension. And I would assert that this is even more important if I have teams working on multiple versions within a single sprint. When issues (usually bugs) arrive, I need to know which version they affect within that sprint as part of my triage and subsequent sprint planning process and leaving that to the end means that I need whoever is doing the bulk update to go through and dredge up the context on each issue to make sure they're appropriately bucketed. Instead I want a way for the people entering the issues to assert a context they're working in since they'll usually be in one for hours or days, and then to have the tickets they enter inherit the context they're working in. Right now, the only context is the sprint and everything other attribute of an issue has to be manually set every time.

[Andre Bickford]

Going by the recommended advice of bulk updating issues after the Sprint has started, another unpleasant situation I've encountered is when a Sprint ends with incomplete stories those Unresolved issues are automatically added to the next Sprint. That's all well and good, except they still have the previous Sprint's Fix Version. Of course, those issues will get updated when I start the next Sprint and bulk update the issues again, but in the mean time when trying to release the just completed Sprint those unfinished issues still have the wrong Fix Version.

Further, we're not great at releasing immediately after the Sprint ends. For this duration of time between when the sprint ends and we actually release, those issues incorrectly lead one to believe they're still part of the just completed Sprint.

More and more I wish Atlassian had re-purposed Fix Versions for Sprints instead of adding a new and different construct just for GreenHopper. It would make things so much easier for us.

[Heath Wolfeld]

We do two bulk updates on the version. One in sprint commit where we bulk edit to add the appropriate fixVersion, and one in sprint review where we bulk edit to remove the fixVersion from incomplete work.

[Mike Johnson]

I have to agree with Andre and Michael above. We use the "Fix Version" as an intent, and if a fix doesn't make the version when we "release" the version, we use JIRA to change the "intended" fix version to another version. The "classic" agile capability seemed to work like Andre and Michael mention -- it uses the "fix version" as the sprint, which was nice and convenient. Now I'm finding that I really want to use the new rapid boards, but the disconnect between the Fix Version and the agile sprint is a headache. Is there any JIRA issue open that I can vote on about "recombining" these notions into one?

[Heath Wolfeld]

I actually like the disconnect between Fix Version and sprints. We sometimes have work that's released to staging at the end of a sprint, but is not released to production until related work is complete. The disconnect allows us to manage sprints and releases independantly.

[Sergey Belyankin]

I don't like it.