Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Org I work in is trying to be agile, but often struggles with respecting the committed scope during a sprint and keeps forcing us to accept new work. This is coming at a cost; happiness and quality.
I would like to articulate this using metrics, but if I just use:
Total Committed (points) vs delivered (points)
Org may think what has been delivered is the new baseline.
Please advise.
Thanks
I would have two concerns over using a committed vs delivered metric to solve this problem:
Org may think what has been delivered is the new baseline
In Scrum terms there is no 'baseline' as such. The Scrum team delivers work according to their capacity to get work items to their definition of done. Typically this definition of done includes measures of quality.
The Product Owner maintains a prioritised backlog of work for the team. It is the Product Owner that might bring additional work in to a sprint. The way they would do this is to talk to the team and inform them that a new work item has appeared that is of higher priority than some or all of the items already allocated to the sprint. The Product Owner and development team may decide to either:
A good way forward would be for the Scrum Master or an agile coach (if you have one) to talk with the wider organisation. Educate them about how Scrum works and the impact of the existing way of working.
Don’t create a custom set of metrics if you can avoid it. Instead, negotiate scope when possible, and leverage the framework’s built-in mechanisms for evaluating opportunity costs against significant scope changes when necessary.
In Scrum, modest changes in scope must be negotiated between the Product Owner and the Development Team, provided that the changes don’t invalidate the current Sprint Goal. In some limited cases, it’s possible to swap out Sprint Backlog items that don’t impact the Sprint Goal, but this should never be considered a routine “business as usual” approach to such a systemic problem.
The canonical approach to a significant change in scope that supercedes the current Sprint Plan or makes the current Sprint Goal obsolete is to cancel the Sprint and return to Sprint Planning.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint.
Aside from the pragmatic reasons for cancellation, which include the need to replan the iteration, making the cost of interrupting in-progress iterations visible to the organization is essential. The cost of cancellation includes the time, labor, and overhead necessary to rescope and replan, and forces the organization to make smarter business decisions about whether the opportunity cost of the new work is truly worth more than the overhead requires to cancel and replan a Sprint.
While there are certainly other metrics you could track, cost/benefit that impacts the project budget directly is generally very persuasive. Furthermore, creating transparency around the impact of replanning on the project’s release plan is also typically more persuasive than trying to measure developer happiness or proxy metrics for quality.
Your mileage may certainly vary, but the framework already provides plenty of opportunity to address this issue within the framework without requiring a custom set of key performance indicators or alternative metrics. Leverage the framework, and only pursue other options when absolutely necessary.
When an organization tries to add more work to an already ongoing sprint, the first reaction of the team should be to try to get the ticket on the backlog, so that it can be prioritized along with the other work and picked up in a future sprint (possibly the next one).
If the work is deemed too important to wait for a few days or weeks till the next sprint starts, then add it to the current sprint as "unplanned work" and negotiate what can be taken out off the sprint to make room in the schedule. Make it clear that due to the addition of the unplanned work, some things that were planned will remain unfinished. That can either be some work that the PO regards as less important for this sprint, or it will be "whatever the team couldn't finish by the end date".
It should be made clear that adding "unplanned work" to a sprint removes any commitment the team has given to the original planning. By removing some work that was originally planned, you might get a new commitment for the new scope. Doing overtime to meet the old 'commitment' in addition to the unplanned work should be so far out of the question that it isn't even considered for one second.
When it comes to metrics, it is best to track the unplanned work separately. For example
This can make it visible how much work the team is doing that wasn't foreseen during the planning and how it affects the amount of planned work that does get completed.
If you want to convey impact on happiness & quality, a points-based metric won't convey that.
Metrics for quality might include escaped defects, or you could report whether & how the Defn of Done has been compromised. Happiness might equate to sustainability, with metrics in overtime hours? Or elevating flight/attrition risk, if retention is a concern in your org.
But the underlying problem is "trying to be agile, struggling to respect committed scope, forces us to accept new work." This sounds like the necessary mindset shift has not taken effect, and I'm not sure how effective metrics will be at encouraging the mindset shift.
Do others in the org understand that the purpose of a fixed-scope sprint is to minimize disruptions so that developers can work most efficiently?
Is there a problem upstream that is causing such lousy planning that new urgent work is regularly being identified mid sprint?
If I had to design metrics to try to illustrate the problem and change hearts & minds, I might use the elements of the agile framework you're using, and report on success/failure to adhere to each of these for every sprint.
A different approach would be to make your sprints shorter. If your sprints are only a week long, then there aren't many business cases where delaying work for 1 week is a dealbreaker.
I second the suggestion of getting an agile coach, if you can, who can coach the whole org, not just the agile teams, in the paradigm shift.
Good luck!
If your team is working on a project which spans multiple sprints, I would recommend that you create a burn-up chart that covers the whole project. Plug in all the estimates you have for the project at user story and at epic level if you don't have user stories for the whole project.
This will create a landing zone for you in the future and will show based on the team's velocity when the team is likely to complete the project.
Now show the organisation the consequences of adding additional work to the sprint and how it affects the landing zone as additional work will push out the landing zone and it will take longer for the team to deliver the project.
