bammar
Kilo Sage
Kilo Sage

Hello All,

 I wanted to share the new BurnUp functionality I developed for my organization after hearing about the need and collecting the required datapoints from our Business Analyst. This is an alternative to the Out of Box Burndown functionality, and it allows for more granular and precise tracking of Sprint tracking. This is going to save our Organization many hours of time because the Out Of Box Burndown did not give us the detail we needed and we had to export data outside of ServiceNow and build Burndowns that way which is arduous and not ideal. Providing the setup- keep reading to see where the BURNUP comes in. Spoiler Alert- Final product image is at bottom of article. 

Building Blocks – The Building Blocks we use are SCRUM TASKS. They are the smallest unit of work. We will use Planned Hours field (2 , 4 , or 8 in our case, other values will work too) to get a precise weight of the scrum task. A BR matches up the Scrum tasks planned duration field to match the Scrum tasks Planned hours.  OOB all scrum tasks default to 1 day planned duration which makes them all weighted the same. So if you had 2 scrum tasks under a story -  one 8 hours and one 2 hours and you closed the 8 hour one- Out of box it will say the Parent story is 50 percent complete……By making sure I control planned duration every scrum task is weighted. So closing the 8 hour scrum task would make the Parent story 80 percent complete in my setup.  OOB only percent rolls up so you have to roll up the planned duration to story to make it work. You can imagine how this could make a huge difference when you move up to Story level.   Key notes- canceling a scrum task removes it from the mathematical calculation. Changing your mind and reopening a completed task sets it back to 0 percent complete

Story Level

All planned durations of a Story’s child Scrum Tasks roll up – So a Story with 100 total hours of scrum tasks has a planned duration of 100 (In my setup points can still be used but they don’t interfere with this). Now lets say you have 2 Stories – the first has 100 total planed hours rolling up from its scrum tasks. The second only 2.  Setting this up like this now Weights the Stories more accurately as well.

Sprint Level

Percent Complete is now perfectly weighted. Our assumptions are folks are creating and maintaining their scrum tasks at least one scrum task per story.  Added a new field called – IDEAL PERCENT COMPLETE.  This new field is populated by nightly process-  it calculates how many days in the sprint ( integrated with our company calendar)  Once it gets that value – we do 100/ working days – then we get the value and populate this field. So for instance  a 10 day sprint means every business day should be + 10 percent ideal percent complete.

Burn Up Data

Every night a snap shot of every active sprint is taken – It grabs the Sprint name, the Date, the Ideal percent complete( calculation method shown above) as well as the now organically rolled up Percent complete.  Using Multidata set reporting, we plot these lines over each other. Voila we have a burn up.

We deliver the Burnups on a dedicated Dashboard. I have also been able to dynamically embed a burnup on a Sprint form- image below. The red line is always at a 45 degree angle showing ideal progress. The Blue is the teams progress and ideally is close to or above the red. If its below either the team is behind and more effort is needed, or the scope is too large and scrum tasks need to be canceled or moved to another Story in another sprint, the beauty of this, is that moving or canceling the scrum tasks in that case will be reflected in the Burn up.

  • No more confusing custom charts or trying to change a custom chart
  • All active Sprints automatically Have Burndown aggregate data snapshots nightly and Burndown built dynamicaly on Sprint page
  • No more periodic or even daily exporting data outside ServiceNow to build BurnDown
  • No more actually creating the reports- unless you want to in a dash
  • Automatic data aggregation
  • No extra work for developers as all work should be documented, all they have to do is make sure they fill in the planned hours which we require.
  • No fighting with custom charts of converting points to mean hours or things like that
  • Easy, quick manager consumption so they can see if team is on track.
  • Visibility and transparency.

find_real_file.png

 

find_real_file.png

On Sprint screen you can see the values- Ideal percent complete auto updated every night. Percent complete updated in real time, new BurnUp Chart plot points also happen every night. Also provided link to Burn UP chart report page in case someone needs to export or even add it as a column in list view. 

If you read this far you must Love ServiceNow as much as I do. I hope this helps inspire you.

Comments
Krishna Reddy3
Tera Contributor

Hi Bammar,

We have same challenge and have a requirement to implement similar solution based on scrum task. Could you please suggest how to implement this technically.

Thanks in advance,

Thank you,
Krishna.   

Version history
Last update:
‎10-29-2020 08:58 AM
Updated by: