Burndown chart for selected sub teams

[vrushali rao]

Hello,

This is my first post here.

We use single scrum board for my project, which consists of many sub teams.

Is there a way where I can see the burndown for one particular team and not the entire project??

Thanks in advance

[Bill Sheboy]

Hi @vrushali rao 

Looking over the solution approach suggested by @Phill Fox led me to wonder how your team works that you want to have separate burn-down and other reporting...

• What is the problem you are trying to solve with separate reporting?
• Does the team plan a sprint, daily scrum, review and retro together?
• Are these teams dependent upon one another to complete work, from start to end?

The answers to these question may lead you to realize that either...

1. This is one team and so there should be one set of supporting reports, or
2. These are independent teams, and so the boards and reporting are independent.

Even with multiple teams, you may find value in having a visibility board to roll-up the work.  But normally teams would not move any work items on that board; instead they would only update their team-specific boards.

Best regards,

Bill

[vrushali rao]

Hello @Bill Sheboy 

Thanks for your response...

please find my answers below.

• What is the problem you are trying to solve with separate reporting?-- I want to see the progress of particular team by having a seperate burn down chart. Since in the current scenario there is one common Scrum board for around 7 to 8 different sub teams
• Does the team plan a sprint, daily scrum, review and retro together? -- No they have separate sprint ceremonies. They dont do it together
• Are these teams dependent upon one another to complete work, from start to end? -- Not completely but few tasks are
  
  Getting independent boards is not possible at the moment, since its a management requirement, to see the entire project progress together

So now, i was wondering is it possible to have filter, and create a separate widget which can give me the same information as the burndown?

Thanks,
Vrushali

[Phill Fox]

@Bill Sheboy 

All great points that you make and I can provide you with several scenarios where you have one project but multiple subteams. However, the most common is where a team gets too big (think 2 pizza rule) to operate as an agile team. They share a common backlog but day to day each subteam works on its own sprint backlog and it is this you would want to track the progress of the subteam against. Whilst at the same time tracking the project progress as a whole. 

There are plenty of other scenarios such as value stream projects with different departments responsible for different phases, 

Phill

[Bill Sheboy]

Thanks for the information and ideas, @vrushali rao  and @Phill Fox 

In this situation, you asked for overall visibility and team-level reporting.  That is certainly possible...

• Use one JIRA project as you have done
• Create separate Scrum boards for each team.  You need something to indicate the separate teams, such as Component to adjust their filters.  The teams manage their work and get reports on these boards.
• Create a Kanban board to show overall visibility.  You do not move the items on this board; you just see them move as the teams move them on the Scrum boards.
• Unfortunately, there is no burn-down or version reports provided for the Kanban boards.  An alternative for this situation is the Cumulative Flow Diagram (CFD).  Ideally, the project only has the relevant work you want to track.  If it has more, you could use an Epic for the "project of interest", and create a quick filter to limit the CFD to that epic.

Best regards,

Bill

[Phill Fox]

Hi @vrushali rao 

Welcome to the Atlassian Community. 

Ok there is a simple solution to your challenge which just requires you to do a little bit of lateral thinking. 

At the moment you have one board that covers all sub-teams and rightly the reports provided with that are for the entire project. You should retain this project board but in addition create a series of new boards based on a filter. These new boards filter would only include the subteam that you are interested in. 

So assuming your current Agile board is defined something like....

project = whatwealldo

we can create a filter for a subteam

project = whatwealldo and subteam = Alpha

This assumes you have a customfield called subteam to identify the appropriate subteam. Alternatively you do not you can use the assignee field with usernames - this fails if you have any unassigned issues though. 

project = whatwealldo and assignee in (Anne, Bob, Carol, Dave)

Once you have the appropriate filters then you can create an agile board based off the filter and you now have access to all the reports but based solely on the subteam. 

There are lots of things you can do with this approach such as splitting up work between development and Q&A teams with different swimlanes/columns to reflect the different parts of a workflow.

Hope this helps 

Phill

[vrushali rao]

Hello @Phill Fox 

Thanks for your response.

Having a separate is not an option for me,since its a management requirement, to see the entire project progress together.

So using the filter is there any other possible option to solve this problem?

Thanks,
Vrushali

[Phill Fox]

Hi @vrushali rao 

My suggestion above retains the single project view for management but gives you additional views for each subteam. 

The boards built off filters are just different views of the same data.

Regards

Phill

[Deleted user]

Hey @Phill Fox 

So if we do your strategy, how does activating the sprints work? Would we need to start sprints in each individual team scrum board? 

If yes, would the main Project Scrum Board carrying all teams data then not have active sprints? Or would we also need to connect each team scrum board to [name] Board for birds eye viewing? 

Or maybe we make the main Project Screen a Kanban locked board?

Thoughts? 

[Phill Fox]

@[deleted] 

I would approach this as being a central board to control all sprints (that includes the work from every team) but then allow each team to allocate their work within their own board. This will allow you to retain a cadence across the group of teams but give each their own independence on workload. 

I often work with organisations who mix and match Scrum/Kanban to get the best approach for them. So for example (and it is only an example) a team that has both a development and a support role may run with Scrum for the development and Kanban for the support. Sometimes removing items from the sprint in Scrum because of external pressures hitting the Kanban board which reduces their availability.