Heterogeneous team sprint time management

[Yaron Tomer]

Our scrum team is heterogeneous.  Member specialize either in frontend or backend domain.  The sub-tasks of a story either go to backend of frontend.  When assigning stories to a sprint, how do I know that the team's capacity was reached?  If it was a homogenous team, the answer is simple --  the team can do 20 ideal days in a sprint (after accounting for velocity), and we've allocated 18 ideal days of task, so it fits.  But in my case I need to know ho sum for each domain individually.   How can I do it in Jira?  

Once the sprint starts, how do I monitor if the team is on track? 

a) Jira burndown doesn't account for subtask completion, only story completion, which is not of fine enough granularity.

b) I'd like to see the burn down per discipline (frontend and backend).

[Nic Brough -Adaptavist-]

I'd like to take a step back to answer this one, and look at Scrum first, Jira second, and making it work for you third.

Scrum looks at what you deliver during a sprint, not how you do them.  You have a list of things to do, agreed and ranked with the product owner, you start a sprint saying "we will deliver these items" and at the end of it, you look at what you delivered.

The (often understated) important point here is a bit "Yoda".  "Do.  Or do not.  There is no try."   An item in your sprint is either done or it is not.   Your product manager does not care if you have split an item into sub-tasks to make it easier for the team to manage, allocate or size.  Your product manager does not care if you did 0%, 1%, 20%, 50%, 99.99% - these are all "not done".  The question is "done or not?"

Velocity and burn down look at that.  Assuming you use Jira the way most people will, issues/stories/features etc are the items that you commit to.  Jira Software looks at those, and completely ignores sub-tasks, because sub-tasks can't answer "have we done what we said we would?"

Now.  There are some damn good arguments for breaking up items into sub-tasks.  There are almost as many good arguments for estimating on sub-tasks.  Despite the tone of what you would find if you looked for my other posts on this subject, and the responses arguing that you should burn-down on sub-tasks (which aren't wrong, they just miss the point), I happily subscribe to sticking estimates on sub-tasks, and, on top of that, using it to report on team progress.  NOT sprint progress - sprint, burn-down and velocity should be calculated from the top-level items I committed to and ignore sub-tasks, but *progress* is a different thing.

Problem here is that when you want to estimate on sub-tasks, you need a system that will reflect what you are doing in the way you want to see it.  And there are lots of different ways people might want to do this.  The three most intuitive ones are:

• Estimate an item, then as people add sub-tasks with their own estimates, subtract the sub-task estimate from the parent estimate.  This has quite a nice self-reflection side-effect in that you quickly know if you have under or over estimated the parent, but the downside is that humans don't work well with negative numbers, and looking at an issue that has "-3 story points estimated and 12 done" looks really strange.
• Create the item with no estimate, and add up the estimates on sub-tasks as they are created.  Easier for humans to see and a lot more intuitive, but forces you to create all the sub-tasks before starting a sprint, which means you lose a lot of the advantages of flexible sub-tasking during the sprint, and kind of reduces the agility of scrum quite a bit.
• Hybrid - give a low estimate on an item, then add up all the sub-task items on to it as they are created

There are other ways to do it as well.

As you can imagine, this makes coding in Jira very complex.  Atlassian have taken the most simple route - ignore sub-tasks and only estimate the Scrum items.

For your case, there are broadly two options:

• Create separate items (not sub-tasks) for each discipline
• Write code that implements the roll-up algorithms that work best for you