SCRUM Rapid Board questions

[michiel ide]

I've played around with the SCRUM version of the rapid board. Some difficulties:

- In the "plan" and "work" board, I can not visualize the subtasks. Is there somewhere/somehow a configuration for this?

- No burn down chart yet? Is this on the feature list?

- We are in a multiple team environment, where each team can work on multiple projects in one sprint, and teams can work on the same project simultaneously. Now, if I understood correctly, a team is represented as a different rapidview? View1 = Team1, View2 = Team2. This tackles perfectly the part "each team works on multiple projects in one sprint" , but does not well for "teams can work on the same project simultaneously", because when you create a sprint, both teams will see the same user stories of the project on their rapid board allthough they should work on different user stories. Am I missing something?

Thanks 4 the assistance, the feature looks very promising to us!

Regards,

Michiel

[sclowes · Accepted solution]

Hi Michiel,

Thanks for the feedback!

Subtasks: At the moment subtasks are not shown in the Plan mode, so there is no way for them to enter a Sprint and appear on the work tab. We plan on addressing this shortly.

Burn down: We are working on that now, expect to see something soon.

Teams: There are a variety of ways you could deal with this, the easiest is probably to have a high level rapid board, then a rapid board per team (and create a JIRA group for each team). You can then plan over the whole project and assign issues in the Sprint to a team lead. From there teams can see their work by using a rapid board with a base query like "project in ( x, y ) and assignee = memberOf(groupName)". Does that sound like it could work?

Thanks,

Shaun

[Mark Stocker]

How have you got the the Scrum Rapid Board? On my version its still greyed out so you cannot select it and I would love to have a play around as we are using are are usign the Kanban board for now.

[Guido Wilken]

Hi Shaun,

thanks for the quick reply!
Actually, this doesn't solve our situation so far, as we use EPICs only for very "large" user stories including several features.

A "new feature" or "improvement" often contains a lot of subtasks, that we would like to be able to plan for individual sprints. The subtasks of a certain feature or improvement are not necessarily done by one and the same developer or, and that's our main problem with the current implementation of the sprint planning, during one sprint.

As of now, you are only able to add a feature/improvement task to a sprint, which will incude all of it's subtasks.

We would need the ability to either add only a certain set of subtasks to a sprint in the planning view, or on the other hand be able to remove unwanted subtasks after all features have been added...

Any chance you could consider this?

I assume that we are not the only ones to work in such a way:)

Currently we create a version for each sprint (very unconvenient...) and still use the "classic" boards.
It would be nice, to leverage the new functionality for sprintplanning, but without the ability to plan individual subtasks, we won't be able to do so.

As the classic boards won't be continued, we'de be pretty much stuck with what we have and don't see a need to renew maintenance...

[Rod Simpson]

If subtasks do not appear in the planning board, and only in the detail view, this seems to imply that subtasks should only ever be assigned to the owner of the parent ticket. Is this correct?

For example, if you gave subtasks to two different people, and only one of the people was going to work on their task in the sprint, there is no way to do this. Either the entire parent, and thus all the subtasks are in the sprint, or none at all.

This also means that subtasks can't be in different sprints from the parent. So even if you assign all subtasks to the same person, you can't put some of the subtasks into one sprint, and other subtasks into a second sprint.

This doesn't make sense to me. Is there documentation somewhere that explains the rational? We have a large catalog with many tickets that have subtasks given to different people, so this is making it difficult for us to transition to the rapid board. If we had an understanding of how these should be used, it would help us evaluate the cost of the transition as well as the benefit.

[sclowes]

Hi Rod,

In general in Scrum tasks are used to break down the technical features necessary for a for the Story (which is the user value) to be delivered. The tasks might well be assigned to different people, but the intention is still to deliver the story because tasks have no value to the customer.

If your sub tasks are actually user deliverable value and are only wrapped in a story to combine them by theme then you might like to try out the new Epic features in labls.

Thanks,
Shaun

[Peter Shiner]

You may have to check the "labs" check box on administration -> "GreenHopper" general configuration

[Vicky Samuels]

I found some similiar discussions on http://www.scrum-master.info . Splitting Epic into meaningful user stories is the right way to go. Prioritising the backlog items will help

[Tom Stokes]

The Classic Board functinality is not replaced by the Rapid and other boards. You should keep this view for people who want to plan in a less "Agile" way. Making a big mistake taking that away.

Tom

[Ade Shokoya]

Hi - is it possible to hide the sub-task from the Scrum work mode view?

Thanks

[Paul Alexander]

Yes, simple.

issuetype in standardIssueTypes()

[Paul Alexander]

Sorry...configure a Quick Filter on the Agile board and use the above syntax.

[Guido Wilken]

Hi,

I wonder how long it will take to realize, that the reality is a bit different from two EPICs "Mars and Pluto" with a couple of new features...

As stated by others, a "New Feature" is often to large to be implemented by one person or in one sprint. As such, being able to plan subtasks in a sprint is necessary.

We manage two large (>100 open "New Features") and a couple of smaller projects with Jira and we do not intend to modify the issue type to EPIC just because the "new / better" implementation forces us to do so. We use EPICs to group new features into larger "user stories" that contain various new features. These new features are perfectly well delivarable value to the customer, while the subtasks they consist of are certainly not. I don't see any reason, why a "New Feature" should be converted to an EPIC just to have all associated subtasks as "new features" which I than have to link manually to the EPIC (while subtasks are associated automatically and it's even easier to hide them in the search...).

What exactly was intended when forcing people to use EPICs for a work process that was perfectly well implemented for New Features before?

Until this is "fixed" or let's call it changed, the new Greenhopper is probably useless for most larger environments I can think of and we are stuck with the old implementation. As mentionend before, there is of course no need to upgrade maintenance until then...

[sclowes]

Hi Guido,

All of my response below is as an individual, I'm not involved in GreenHopper day to day any more, so I'm just sharing my experience.

It sounds like you have 'Feature Group' (issuetype Epic) > 'User Story' (issuetype Story) > 'New Feature' (sub task). The use of 'New Feature' is a bit confusing because it seems like the 'User Story' is too large to fit in to a sprint so it's decomposed in to 'New Features' which are 'User deliverable value' (i.e. user stories themselves).

It seems like you're fundamentally attempting to achieve three levels of story depth, i.e. Epic > Sub Epic > Story. Your use of 'Sub-Tasks' for the 'New Feature' to achieve the last connection is not going to work for many teams since they actually use sub tasks to indicate the technical items that must be completed during the sprint, since sub-tasks cannot have further sub tasks your current arrangement prohibits that. Is this what you refer to when you note that 'a "New Feature" is often too large to be implemented by one person or in one sprint'? If it's too large to complete by one person you probably want to break it in to sub tasks right? If it's too large to be completed in a sprint would it make more sense to break it out in to more stories?

Would an arrangement like 'Feature Group' > 'Epic' > 'New Feature' > 'Sub task' work?. Here I'd link the 'Feature Group' issue type to the various 'Epic's (issuetype Epic), then use the GreenHopper features to link the Epic to the New Features (issuetype New Feature). I could then use sub tasks as normal to indicate work to completed during a sprint and break the work amongst many individuals. For 'New Features' that are too large to be completed in a single sprint I'd split the story in to smaller chunks and link them to the Epic (and remove or archive the old too large story).

You could potentially even do all of this using issue links rather than the new Epic support at all.

Cheers,
Shaun

[Guido Wilken]

Hi Shaun,

thanks a lot for your quick reply!

Actually we use the issuetypes as follows:

A 'User Story' or 'New Feature' (issuetype "New Feature" or "Story" as you call it) is divided into a couple of subtasks of the type "Development". These are default Jira issuetypes, so this makes sense for us. Usually each subtask of the type development is done be individual developers but not necessarily being different ones. Usually a new feature needs development in different parts of the software (for example a new JSP, implementation of a WebService, inclusion of a new library... stuff like that). We add subtasks of the type development for each of these things to do and they may get picked up by different developers (backend, frontend...) in different sprints.

We use EPICs only very rare, to avoid cluttering the system with EPICs and having one for each (even small) new feature. EPICs usually represent a "large" userstory that may consist of various new features to deliver it.

If we would be "forced" to use an EPIC for each and every new feature we would need to convert 200+ issues of the type "New Feature" and as well completely change the well established process for 20+ developers + QA and so on... For us, this is - unfortunately - a no go, and thus we cannot use the "new" sprint planning...

[sclowes]

Most of your arrangement sounds typical, indeed 'Development' is a very logical task that needs to get done, often in multiple different software components, to deliver a story. The part where you lose me is how this implies that these tasks should be able to enter a Sprint by themselves.

Philosophically speaking a sprint is about delivering user value, since freestanding tasks don't provide usable features for users they can't deliver value by themselves. Thus including a task by itself in to a sprint doesn't provide a measurable sprint outcome.

To compound the above problem the purpose of a task is simply as a waypoint to delivering the end user story. The team needs to focus on delivering the user story value by whatever means possible, by doing so I've often seen teams decide to drop tasks entirely and use different approaches. A task doesn't hold enough context to be worked on in a sprint by itself, the parent story has to be the focus.

Technically it also doesn't make sense because most Scrum teams break down items in to tasks then track the completion of those tasks during the sprint (using the burndown) to be sure that the work will be delivered. Since tasks can't be broken in to tasks the team can't do this and potentially cannot track the progress of the work to the level of granularity they wish.

You could definitely recreate your existing process using issue links and return sub tasks to their normal use (you wouldn't need to use the new Epics at all). Sure, this would require some process change but I would hope that the value you derived would be worth it. Is there a specific part of your current arrangement that you really like in the UI? It is a similar level of effort to do this as to use issue linking.

Again, all of this commentary is not related to GreenHopper, for what it's worth I've personally worked with teams that have achieved incredible success by focusing on delivering end user value through stories.

Cheers,
Shaun

[Guido Wilken]

Hi Shaun,

I guess, that our work processes are not enough aligned to SCRUM then, as we use a sprint rather to organize the development efforts itself than to focus on user deliverable content. As such, the sprint review meeting often get's quite short, as only a few user stories are finished and able to be presented. The development efforts attached to user stories or new features are usually larger than a single sprint.

In terms of SCRUM, I agree, this usage of a "new feature" / "user story" is not right, as they too often do not fit into a single sprint. On the other hand, this usage is very SCRUM-like, the only problem is, that the development effort connected to a single feature is usually too much (and thus broken down into the seperate development tasks) to fit everything into one sprint. But as at least the two larger projects we manage have very complex interactions with other systems a single deliverable user story consists of a lot of different tasks.

To align this more to a real SCRUM process it would be possible to perceive the different development tasks as new features available in the product itself or to a developer, but not necessarily to an enduser. But this would still require us to rearrange ALL of the existing issues planned... *sigh*

Thanks for your input! I will roll it around in my head a little and see what I can make of it :)

[André Sander]

Lets say I have a parent issue with 2 larger subtasks - how can I assign subtask 1 to sprint 1 and subtask 2 to sprint 2?

Usually our parentask have a much bigger time estimate then a sprint has days - so we do have to split them up.

Any suggestions?

Thanks, André

[Paul Alexander]

Option #1:

Use an Epic to contain the work product (goal you have set that you want to achieve). And then split out the stories into manageable pieces of business functionality (and assign story points if you desire). Create subtasks as needed under each story. Then, link the two Stories to the Epic. Then put Story-A into Sprint-1 and Story-B into Sprint-2.

[Brian Boarini]

We're having an issue moving sub-tasks across a Kanban board. Stories can be moved from column-to-column, but sub-tasks cannot be moved.

Any insight into why this might be?

[Nicholas Muldoon]

Hi Brian,

Are you using the GreenHopper Simplified Workflow?

Thanks,
Nicholas Muldoon
@GreenHopperTeam

[Guido Wilken]

"Subtasks: At the moment subtasks are not shown in the Plan mode, so there is no way for them to enter a Sprint and appear on the work tab. We plan on addressing this shortly."

Hi,

we're looking for the exact same feature as we would like to plan subtasks in sprints as well.

"shortly" seems odd, as it's still unaddressed after more than 10 months.

Do you still plan to implement this?

Is there a workaround until you do?

Cheers,

Guido

[sclowes]

Hi Guido,

We actually shipped this long long ago (I think somewhere around GH 5.10.6 or so). In plan mode the sub tasks appear in a tab of the detail view, in work mode they appear as separate cards.

You cannot include sub tasks in to a sprint without their parent story.

Thanks,
Shaun

[Rod Simpson]

Shaun,

Thank you for answering. I suspected that was the case, so thank you for confirming.

Rod

[Blake Benthall]

Are subtasks still hidden on the Plan board? This is a huge impediment, especially now that the old Planning Board is deprecated.

[sclowes]

No, this question is now very old. Sub tasks have their own tab in the detail view for their parent in plan mode and appear as cards in work mode.

Please note that the Classic Planning Board is not deprecated, it's just not being actively improved. We will continue to provide critical bug fix support for it for the forseeable future.

Thanks,
Shaun

[Mark Stocker]

How have you got the the Scrum Rapid Board? On my version its still greyed out so you cannot select it and I woudl love to have a play around as we are using are are usign the Kanban board for now.

[Nicholas Muldoon]

Hi Mark,

Please ensure you are on JIRA 4.4.4 and GreenHopper 5.8.6. You can then create a new board from the Scrum tab on the Getting Started page, you will see a link in the lower left hand corner.

Thanks Mark,

Nick