Burndown chart using % complete remaining instead of story completion

[RyanAshline]

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

[phsdm · Accepted solution]

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.

[RyanAshline]

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

[phsdm]

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.

[kellykaufmann]

Hi Peter

For when your company is ready to discuss the best use of ServiceNow PPM for the various types of efforts being worked on, I wanted to pass along the following to have in your back pocket...note that the SN versions vary but the concepts remain.

• Expert Dialogue : Highlights of Real-Life Configurations of PPM for I.T. Requests
• Creating a PMO Blueprint with ServiceNow

I have some various decks as well that I put together at past employers, going through SN setup options that I can pass along as well if desired.