I just wanted to throw this question out there:
We use a Scrum board across many projects. We group our stories into sprints based on the fix version on the stories (so all issues for Project X v1.2 will be in the same sprint). We sometimes use epics to help with this. However, in this case, it would be simpler to just have the fix version display on the stories in the same way epics do. Would this make sense as a new Greenhoper option? or would this not be considered best practice?
You should use the old boards (Classic) in your case, if you need to filter issues based on versions.
Displaying the fixversions on the left may not be a good practice in the new boards as the boards can cater to mulitple projects.
You may use a quick filter in the boards using the JQL (earliestUnReleasedVersion) so that you can quickly filter the issues.
You mention plan mode, so I assume you are speaking about the new (Rapid) boards.
You probably are aware that the (rapid) board has resulted in a decoupling of Sprints from the Fix Version field, Fix Version is back to its intended use-case (showing which versions a bug or story can be found in).
So using fixVerision to group stories is not best practice with the new boards, if using the new boards sprints should be organised around the new Sprint field.
We do use sprints separately from fix Versions, but we generally still organize our sprints by versions. for example, "Sprint 10" may include stories from "project x v1.2" and "project y v2.3" because to ensure we have a releasable product at the end of the sprint, we want to make sure we include all work for a given release version. sometimes stories for a given version get spread across many sprints, if there is a big release and we want to do check points, or break the work up into smaller chunks, but the fix version information helps us with planning sprints. Am I off-base?
You are not using fixVersion as now is recomended. It is hard to change mid project though. We are waiting until the end of our release and the start of a new project in January to stop using fixVersion to manage sprints as our complete feature release has used it - indeed that is the recommended path.
You are using a (Rapid) Board and best practice is that you do not manage sprints with fixVersion. Have you invested many sprints in using fixVersion like this?
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG