Migrating from Classing Planning Board to Rapid Board

Mark DeMichele September 24, 2012

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

0 votes
Answer accepted
sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 24, 2012

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

Mark DeMichele September 25, 2012

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.

Mark DeMichele September 25, 2012

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.

sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 26, 2012

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

Mark DeMichele September 27, 2012

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