Migrating from Classing Planning Board to Rapid Board

I'm trying to migrate from using the Class Planning Board to the new Rapid Board for scrum. I've run into a few pain points that I would like to describe and maybe someone can suggest ways to deal with them.

1. When doing our iteration planning. We would first determing an available load for each of our members. Then we would use the Jira Version Workload Report to make sure that the number of stories assigned to each user kept each user inline with their availablity for the iteration. I can't seem to do this with the new "sprints". In fact, how does Jira see these sprints. It seems Jira is completely unaware which seems like a bad thing since now this will render a lot of jira reports useless. I'm hoping I'm missing something here.

2. On the "Plan" view the rapid board, I can't seem to customize the card view. I want to see assignments. I realize the true agile teams aren't supposed to assign stories until they are worked on, but that's not the way our team works. Our team members know exactly what each one has committed to at the start of an iteration. How can I do this using the interface?

3. It seems that all the reports are on the current "sprint". What if I want a report on a past or future sprint? How do I do that?

4. Why did you separate versions from sprints? It seems like a bad idea. Versions were working perfectly for us.

1 answer

1 accepted

Hi Mark,

1. That's correct, the new sprints are completely separate from versions.

2. We do not currently plan to allow customization of the cards in the new boards. You might like to try adding quick filters for your team members.

3. The reports will all work for historical sprints (i.e. the velocity report, sprint report and burndown all work for historical as well as current sprints).

4. Separating the two was actually one of the most requested features we've ever had for GreenHopper.

Thanks,
Shaun

One other question. In the classic set up. We created a heirarchy for out versions so that we had a parent version for the entire release, then a child versions pre-code freeze and post-code freeze and defferred stories. Then we put our iterations inside those children. This gave us the ability to create reports for the entire release, the work to be done prior to our official code-freeze and after our official code freeze. Plus is during the release we decided a certain feature was a candidate to get deferred to the next relase, we moved it to the deffered version. This allowed us to keep it available just in case things change (like getting more resources). Do you have any suggestions on doing something similar with Sprints. Is there a way to assign versions to Stories in sprints. Is that the solution? We just maintain both structures? Seems time consuming.

I have some follow up questions.

1. Do you have suggestions on how, during a planning meeting, we can build our sprint based on Story points per assignee. In our team, we tend to specialize a little bit, so it's important that the stories we chose will reflect the loading the each individual team member. What I did this week was to set the option to color code by assignee. Then I maniuplated the backlog (and sprint) to manually group the highest stories in the backlog by color (assignee). Then I manually counted each individuals story points. This is not nearly as nice as when I just went to the Version Workload report and viewed it.

2. Is there a way to type in a quick search filed to see a particular assignee. We have about 15 team members, I don't think I want to have 15 button across the top. Also, in the classic boards it was possible to look at a task board prior to starting the iteration (version). Now you can't. That's kind of annoying. I have to admit. I'm question whether this is a move forward, or sideways. I'm noticing a lot of lost functionality for my team.

4. Is there any way to use JQL to build reports based on sprints, like where sprint = xxx. I haven't been able to find that.

1. Points per assignee: The best way for now is to create 15 quick filters then toggle those on (so you'll see the points assigned to that user in the sprint footer when the filter is on).

2. Quick search by assignee: This is a feature we'd like to implement, for now you'd need to define the 15 filters

3. Task board prior to starting the sprint: Could you provide some detail about why you want to see this?

4. JQL based on sprints: Not trivially (you can do it as long as you know the sprint id), the way we intend users to access this functionality is via the Sprint Report (which contains links to the issue navigator). We will definitely implement JQL operators for sprints in the future

5. Version Planning: For many of our users joining sprints to versions was a huge pain. You can continue using versions, for example you can use the sprint report, click on issue navigator then bulk edit all the sprint's issues to assign them to a fix version. Regarding the 'Deferred' issues, I'd suggest just dropping them from the sprint and leaving them at the top of the backlog (so they can be re-added if resources become available). We'd like to look further at release planning at release planning features in the future.

Thanks,
Shaun

3. The task board is the only way I can easily see stories per assignee. BTW, we can really use some sort of summations of remaining time, estimated time or story points per swimlane.

4. I feel this is a major oversight. What I found to be a key feature of greenhopper before this rapid board change over is that you would use all sorts of jira reports and dashboard items to view your data. By totally separating sprints that's not possible anymore. You basically lost tons of "Free" features. Also, don't tell me I can still use the classic considering you constantly have to click extra manu items to get there and dimiss warnings and live with the fact that it will never be improved, it's not much of an option.

5. Out release is made up of 100's of stories and many iterations as I'm sure most large projects are. Sometimes, early in the project, we decide that a feature needs to go into deferred. I really don't want the 20 user stories associated with that feature to sit at the top of my backlog. I guess we can put them at the bottom, but once again. This is a step backwards in my oppinion.

One last thing, and don't get me wrong. I really like greenhopper and I'm exited you want to improve it and move it into the future. However, I'm tired of hearing that "many users wanted us to separate sprints from versions". If you look through this forum, you can find tons of posts where people are complaining of this separation. I just hope you didn't listen to the wrong group and now have a mess on your hands. I write software too, and I've seen a few bad design descisions in my day. Please don't take it personal but I fellt the need to voice my oppinion since I'm now spending manyu more ours using this "improved" tool doing what I used to do and not doing it as well.

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Sarah Schuster
Posted Mar 28, 2018 in Jira Software

Can a company’s culture make or break agile adoption?

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...

12,056 views 15 13
Join discussion

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you