What is your focus: increasing metrics or improving processes?

Question

I noticed (in our company) that Scrum Masters have one of the approaches:

1. Start with metrics and work on improving the numbers: e.g. a new user story comes up during sprint, the team might reject it because it affects velocity. So the decision making process is centered around the metrics and how that action will influence the metrics and the team performance.

2. Start with value and focus on increasing value: e.g. a new user story comes up into sprint, how important is that user story for the product (or valuable) => decision is entirely made based on this. Affected metrics are irrelevant, as long as you know why the delta happens.

3. Start with process and focus on process improvement: e.g. a new user story comes up, putting it up during the sprint will disrupt the sprint and probably lower performance overall, so the team decides to leave it out (even if the story would increase the product value) and do it in the next sprint.

My teams and I combine 2 & 3 (if value is high, we add it to the sprint). But I saw a focus on 1 a lot for example.

So my question is: what do you focus on? How do you make decisions, and what do you thinks are the drawbacks of choosing only one or another?

Answer 1

I'll answer this more generally because I am not an Agile guy. You are hitting on a systemic issue with the concepts of metrics and that is you can end up rewarding and promoting the wrong behavior while extinguishing the desired behavior. Our culture, at least in the US, is very "results oriented". When you have this onlyresultsmatter,whatyoutriedtodoisirrelevant mentality, then you end up with results type metrics and the behaviors that get you there are what will prevail, and the risk could be behavior that you described or even worse such as something illegal.

In my view, it is very myopic to create your metrics like this. That's not to say that some results type metrics should exist but I think there should be other metrics that are tried to the behavior, too.

In my view, process and value are linked. So if your approach to process is one of continuous improvement, constant leaning, etc., then I think value is maximized for the product being produced for the customer. So to answer you question, my focus would be a combination of your 2 and 3, maybe with more focus on 3 first with the assumption that value follows.

Answer 2

This is a great question as it is not an uncommon concern.

What are metrics? A way to measure something. Of course they need to be valuable; if not, stop collecting them. If metrics are the basis of team decisions, then there is an opportunity for improvement. That is a red flag that priorities are not where they need to be for the business and/or the team. Remember the manifesto: "Working software is the primary measure of progress."

What is a Sprint? A time-boxed event to create focus and limit risk. If new work is being interjected (or even considered for injection) especially regularly, then there are concerns. How does the Development Team focus on the forecast and Sprint Goal from the Sprint Planning event? How does that affect risk?

What does The Scrum Guide say about modifying the Sprint Backlog during the Sprint?

• No changes are made that would endanger the Sprint Goal
• Quality goals do not decrease
• Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned

Ideally, once the Product Backlog is set at Sprint Planning, items should only be added or removed if they pertain to the Sprint Goal and do not affect the quality of the Increment.

If something is truly that critical that it warrants changing the plan, then there are factors to be considered.

• Has the item been refined and is it understood? Can work being immediately?
• How does inclusion affect the current items? Are in progress items abandoned or completed with not yet started items being dropped?
• Is there time and are there resources in the Sprint to complete the new item?
• What is the effect of not including it?
• What is the impact on the Development Team and Scrum Team? It is very disruptive to break (especially frequently) the Scrum framework pattern of events.

Since each Sprint is less than one month in length, there is generally not a high loss of value for making it the highest item on the Product Backlog for inclusion in the next Sprint. Perhaps there is more refinement needed in order for it to be Ready, so be sure to factor that into adjusting the current Sprint.

The Product Owner is the only one who can cancel a Sprint. The Scrum Team is to be self-organizing, so have a conversation. Understand all of the risks to both the current Sprint items and the new item. Disruptions affect the product and the individuals. (see "Agile processes promote sustainable development.")

More generally, regarding the post title: Improvement (product, learning, processes) is more important than metrics.

Answer 3

As a Scrum Master my focus is on helping the team to improve.

Every team is different. Some like to focus on metrics. Others are passionate about business value.

My job is to help them to achieve success with whatever tools or approach they choose. I may also offer them alternatives where appropriate, but it always comes back to the team's decision.