Sprint Burndown in Jira

Hi Katherine,

It seems a bit that JIRA becomes more leading for the process of the team than the ability to adapt on their inspections.

It's a good thing that the DT want to inspect their progressing towards the sprint goal, but the number of story points, JIRA tickets done of whatsoever does not necessarily mean that they are achieving the sprint goal. Inspect the current state of the backlog compared to time left to reach the backlog and if these SBIs are still the relevant items to achieve the goal itself. 

Please don't misunderstand me that I think that a sprint burndown is not a valuable metrics, because I absolutely think it is very useful in case it is used for, for example, improve your process. Inspect and adapt on your predictability etc. 

Besides that, the term "best" is very much relative to the team, like story points itself. What works best for your team doesn't per se mean it works best for other teams as well:). 

That being said, some more specific answers to your questions:

1: I'd say instantly, as the sprint starts directly after the previous one. Most common thing I see is after the sprint planning.

2: If you add work, the chart will show this. 

Hope this is useful to you, enjoy the remaining part of your weekend!

Reach the goal of course*

Thanks Sander.  I still don’t understand why a burn down can’t or shouldn’t be used to measure progress to sprint goal given (a) a sprint goal is being committed to (the team does not commit to the forecast or backlog items but does commit to the sprint goal goal) and (b) historical and projected capacity of the team (c) jira stories should be very transparent in reflecting how a team achieves the sprint goal (d) sprints are time boxed after all so there should be a way to define this time while maintaining flexibility for empiricism in between  Given these four things, it makes sense to me to officially start the sprint when the story points of the PBIs is less than or equal to the projected capacity.   This could be done in sprint planning before SBIs are created.  From there, new stories (SBIs) are created subtracting from PBIs.  SBIs are crated as the work emerges so the process is still empirical.  The scope feedback at the end of a sprint could help team with estimating (yet another opportunity to learn from feedback and then adapt?). I also see jira stories as being used to meet the goal of transparency of details/value delivered.  Jira can and should be used to realize and facilitate Scrum not replacing any part of Scrum.  

I’d really appreciate more feedback and especially how other Scrum Masters out there use Jira and how they use burn downs if different from this.  Also, is any labelling or anything else used to differentiate PBIs from SBIs?

thank you,

Katherine

From there, new stories (SBIs) are created subtracting from PBIs.

Also, is any labelling or anything else used to differentiate PBIs from SBIs?

Katherine - what do you mean by SBIs? I've never heard the term before.

The PBI (Product Backlog Item) represents the user story. During Sprint Planning, and during the sprint, these are decomposed into tasks that represent the work to be done. In practice, this means the team will go into the tool of choice (or a physical board), create a new Task, give it a Title, end maybe give it an estimate of hours.

I haven't used Jira recently, but I imagine that the PBIs will stay the same but tasks will change (created, removed, set to Done, etc).

Hope that makes sense.

Hi Ben,

Thanks for taking the time to comment.  SBIs are Sprint Backlog Items.  The Sprint Backlog is composed of the PBIs and SBIs.  I'm guessing that your use of Jira would be: keeping the PBI as-is in terms of story points but creating sub-tasks (since you refer to "tasks") for the SBIs or breakdown/realization of the PBI, creating new sub-tasks as the work emerges in the Sprint, and that the story points would stay in the parent story, and the sub-tasks would all have zero story points?

Katherine

Just to clarify, "The Sprint Backlog is composed of the PBIs and SBIs." should have said "The Sprint Backlog is composed of the PBIs that the Development Teams takes into the Sprint from the PB during Sprint Planning (the What) and SBIs (the How)".

Suppose you had one Sprint burndown chart in story points, and another Sprint burndown chart in task hours. Each would give a different view on progress yet both might prove useful. How might a team use both kinds of information to evidence Sprint control?

I use Jira now and honestly it is lacks a lot in it's implementation of agile and especially Scrum.  The only way that the burn down charts will work is if you have items that are 1 day or less in size and it does not burn down sub-tasks, only stories.  In my experience with teams, they have found it to be more work than is useful to create stories at 1 day increments. This is especially true if you have more than one story in progress at the same time. There is a lot of overhead involved in decomposing things to the finite levels. The burn down of larger stories from the Product Backlog is still useful and I actually believe it is better because it shows the progress towards the forecast goal of delivering value since the PBIs are the items that actually identify the value. 

As for monitoring the progress towards the Sprint Goal, isn't that the purpose of the Daily Scrum?  Do they really need to have some kind of chart to do that? What happens when you discover new work during the process of doing the forecast work? In your case of <=1 day stories, creating new ones indicates that they are monitoring their progress without the use of a chart.  What if they find some of the  <=1 day stories are not needed after all? Do they mark them done or delete them?  To me marking them done is usually to make the chart look good where deleting them is actually managing their work as that planned work is no longer needed.  Relying on charts are good for beginning teams to help them start to see/appreciate the effort of continuous progress. But I don't like to coach my teams to rely on those only. I have seen teams revert to bad practices just to keep their charts look good. 

It seems to me you're over complicating things, Katherine, although I bet you have the best intentions. Let me clarify.

• First of all, each team is unique. There is no panacea in terms of work habits, tools, practices, etc, that would apply to all teams.
• It's great the DT want to monitor their sprint goal progress. But why do they have to link it (the monitoring) to a tool/process via JIRA? They already have the daily scrum during which they could and should inspect such progress; and throughout the day, they can also engage in as many interactions as they deem appropriate (SG: Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work)
• "I see one possible way of doing this to create a "Sprint Burndown" using the Jira tool but have a questions about the functional details."  JIRA already offers such a burndown via the Reports function. 

• Say in Sprint Planning, the team pulls a particular PBI from the PB and it has a story point estimate of say 30 story points.  From there the DT will refine the implementation details and create SBIs.  I understand that best practice is for each PBI is to have an estimate of <= 1 sprint and each SBI to have an estimate of <= 1 day. 

There is no such separation: there are only product backlog items (PBI as you refer to it). if they are selected for a sprint, their "title" changes into sprint backlog items to acknowledge the fact said backlog items are actively covered in a sprint. (SG: The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.)

• I have two questions.  (1) what is best practice for when the "start sprint" button is hit?  You obviously want the total story points to be the total projected amount of work the DT thinks they can complete in the sprint because the burndown needs this as an input when it's created.  Is it best to hit "start sprint" once all the PBIs are contained and before SBI's are created?  (2) From there, as SBIs are created, they subtract story points from the total/bucket in the PBI's?  If the total of the SBI's ends up being greater than the total of the PBI's then that would show in the dashboard as scope change? ... I do understand that in Sprint Planning, the DT should decompose at least the first few days' work into SBIs, I'm just not sure on best practice for these two questions around the functional aspects in Jira (1) at what point to hit "start sprint" and (2) how to shift story points from story to story (PBI to SBI) after this button is hit.

1. No best practice - button being hit is really the last worry the Scrum Team should have during sprint planning. The Sprint Goal, the plan for targeting it, decomposing work for the first day (or few days) - those are the priorities. And not really, total story points may not necessarily be the total projected amount of work (ie, the team may uncover further work to be done towards the sprint goal > which means new tickets raised > may mean extra story points; or, if the sprint goal is achieved and all tickets are done, the DT can pull other items into sprint)

2. Why substract anything? Why shift story points from PBI to SBI (which, again, are just PBIs)? Your purpose is to deliver value via a potentially releasable increment, not to add, substract, divide or multiply story points. 

Hope this helps.