5 Replies · Latest reply on Dec 20, 2017 7:29 AM by Edward Smith

    Burndown chart using % complete remaining instead of story completion

      I have a seen a couple scrum burn down charts online that have the assignee update the percent to complete for their story.  This is then used to calculate and plot the burn down chart.

       

      I know SN triggers on the story state moving to one that sets the story to inactive, but does anyone know or has anyone seen anyone who was able to adjust the burndown chart to calculate on a percentage to complete?

       

      I know it's a long shot thought i'd throw it out there.


      Ryan

        • Re: Burndown chart using % complete remaining instead of story completion
          Peter Smith

          Many advocates of Kanban, Agile, Scrum, etc. will cringe at this approach.  A story is either complete (in production) or not.  Can a stakeholder tell the difference between a story that is 99.999% complete, compared to one that is 0% complete?  I believe that's why the ServiceNow scrum/agile support doesn't offer this feature.

           

          So you ask, "How do I show incremental progress?"  This is where backlog refinement comes in.  A story should not be moved from the release backlog to the sprint backlog until the adopter agrees that it can be completed in one sprint.

           

          To stop the sprint backlog from looking like a step function, consider marking stories complete when they have been tested and added to the sprint RFC.  That way the easy stuff that gets done on Day 1 will track with the ideal completion line.

          Peter H. Smith | Senior Consultant | Sparkhound | (919) 423-3693

            • Re: Burndown chart using % complete remaining instead of story completion
              Ryan Ashline

              Thanks for the reply Peter.

               

              I agree with you completely that messing with the calculation is fundamental to the frameworks and should not be modified.  I thought about it some more after posting and came up with a few solutions that will help me get a little more of what I'm looking for.

               

              We have a challenge in that our team is not allowed to be that perfect scrum team and be 100% focused on the sprint.  Some on the team support incidents as well, as some routine support request.

               

              I like the idea of setting the testing state as complete, i am going to give that some more thought.

               

              For now I am going to use Time Card application to help me get a closer idea on how things are going.  We require are team to code time to all their work.  We have expanded the time card application to code time to incidents, request and projects.  I think we will add this functionality to stories then i'll be able to watch the daily time coded and calculate delta's between actual and estimated.  That will also allow us to use that data to get better at estimations.

               

              We are new to using scrum and are learning along the way

               

              Thanks again for the reply

                • Re: Burndown chart using % complete remaining instead of story completion
                  Peter Smith

                  Ryan,

                   

                  We are in a similar position.  I pushed to implement Scrum for the ServiceNow delivery team with partial success.  We have a somewhat effective Scrumbut pipeline.

                   

                  You should look at Demand Management.  The broader ServiceNow Strategy/Design/Transition pipeline now supports waterfall, product-oriented agile, and project-oriented agile.  It is tempting to try to bend the Scrum module to reach into those areas.  I started out doing that.

                   

                  We have three levels of reporting:

                   

                  • Initiatives (Strategy):  Support for execution of strategy.  Of interest to upper level leadership.
                  • Projects (Design, Transition):  Large deliverables that support initiatives.  Of interest to the PMO and directors.
                  • Details (Transition):  Small deliverables that support projects.  Of interest to the delivery team.

                   

                  We use the Scrum module to handle details.  We need Demand Management for initiatives, and integration with the PMO for projects.  The Scrum module originally supported the StartNow process, and was detached from the broader demand and planning pipeline.  Since Geneva, it has been integrated with Demand Management, Release Management, etc.

                   

                  We haven't implemented Demand Management yet, and we can't convince the PMO that they should import projects from MS Project to ServiceNow, to provide better integration of the delivery pipeline.  So, here's what we do in a nutshell.  We rely on the Scrum module constructs as follow:

                   

                  • Products for project feature/requirements tracking.  This is not ideal, but gives a place to store and surface unrefined requirements that aren't being worked.  I think this would be replaced by the Demand pipeline.  We would use Themes and Epics for cross-cutting activities, but Themes are many to one with Products, not many to many.
                  • Enhancements/Defects for approvals.  This is a PITA because the scrum team is saddled with manually associating Stories to Enhancements/Defects.  I would just use stories.  Enhancements/Defects are legacy constructs for us.  We started using them before we started using products, releases, themes, and epics.  Also, we have issues with surfacing micro progress to stakeholders.  Visibility into weekly progress causes stakeholders to lobby for their priorities, and we don't have a mechanism for planning poker or the collective will to limit each kanban to achievable WiP.
                  • Releases/Sprints/Stories for execution.  Releases backlogs hold stories that factor project requirements, and unify work across projects (products.)  Since we only have one delivery pipeline and don't have automated testing, we need to synchronize to minimize conflicts and manual test.  Sprint backlogs hold stories that have been factored into sprint-sized nuggets and have developer commitment for completion in this sprint.
                  • Epics for cross-project reporting:  Epics are many to many with Products, so we can use them effectively.

                   

                  We also have a Maintenance product where we put our stories related to KTLO and sharpening the ax.  Ideally, we would carve out 20-40% of each sprint to clear the backlog.  At least we have a way to track and surface accumulating technical debt

                   

                  I looked at customizing the Scrum module before I heard about Demand Management.  I'm glad I didn't do it.  It would be better to use Demand Management upstream, and Release/Change management downstream.  After a while, we would know where to invest a small amount to improve throughput and transparency.

                   

                  I'll attach a slide deck that I tailored for our situation.  It's pretty rough, but explains how we get along without Demand Management.

                  Peter H. Smith | Senior Consultant | Sparkhound | (919) 423-3693

              • Re: Burndown chart using % complete remaining instead of story completion
                Edward Smith

                Hey, I wanted to chime in on this as we too are trying to make the burndown chart useful as part of our recent adoption of ServiceNow for our agile development process. 

                 

                I disagree with the answer and how ServiceNow has implemented the burndown chart.  The problem is, even if stories are sized such that they can all be completed in one sprint, the burndown chart is useless unless the stories can be completed in a small fraction of one sprint.

                 

                For example, if a 2-week sprint has 5 developers and 10 stories each averaging 1 week, then the burndown chart would be completely flat for the first week and then take a big jump down as the first round of stories are completed, and then flat again until the end of the sprint.  That is kind of an extreme, but my sprints tend to have a mix of stories where 50% of them take less than 4 days and 50% of them take 5-8 days.   The problem is that once the short ones are all done, the burndown chart goes mostly flat while the longer ones are worked.

                 

                The solution is, as ryanashline suggested, to allow for some form of tracking of 'percent complete.'  I've done it differently than that in the past, but fundamentally, there should be some way to track partial completion.  Not the the purpose of carrying a story over from one sprint to another, but simply to allow the Scrum Master to see if the sprint seems to be on track or not without having to do the 'percent complete' math in their head during every scrum.