Is measuring Sprint performance really mandatory?
My PSM exam prep material states in one of its simulation questions, that "using Sprint backlogs" and "measuring the performance of the Sprints" are both mandatory in Scrum. In the explanation it says both are artifacts in Scrum and thus both are mandatory - which directly put me off. How are performance measurements Scrum artifacts? This can't be right...
And what is actually meant by "measuring the performance of the Sprints"? If we are talking performance, we are talking velocity, right? Now I get it doesn't need to be about Story Points, but some kind of abstract comparison of Sprint accomplishments over time. However, I found nothing in the Scrum Guide which states, that this is neccessary at all, since we're all about delivering valuable software in the end. Keeping track of performance in that regard might actually turn out to be a key figure in an effort of getting better and more efficient and thus delivering even more value - but who says it's mandatory???
I'm confused - please help a Scrum Master out :)
What exam prep material are you using?
The Scrum Guide mentions a number of artifacts required by Scrum. One of these artifacts is the Sprint Backlog, and is defined as "the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal". Throughout the Sprint, the Development Team can modify the Sprint Backlog to reflect the current state of work or add new work that is discovered as more is learned.
However, the Scrum Guide does not mention "measure", "measurement", "velocity", or "Story Points". It does mention inspection. The various Scrum artifacts (the Product Backlog, the Sprint Backlog, and the Product Increment) are inspected to monitor progress and detect variances. The inspection is used to allow the Scrum Team to adapt, to reorient itself to effectively deliver value. Scrum provides for four events to perform inspection. Measurements may help to inspect and adapt, but Scrum does not mandate any particular measurements or metrics.
What information do the various people involved need in order to adequately inspect and adapt?
Hi Thomas,
What exam prep material are you using?
It's a third-party PSM I exam prep.
What information do the various people involved need in order to adequately inspect and adapt?
Totally up to them I'd say. Performance measurements may bring transparency to the question about overall performance - which could be of interest for everyone involved and having an interest in the Development Team performing better - but it certainly depends on the project context.
So you're saying it's not mandatory. Good - I'm not the only one getting this impression. Would you go so far to conclude that the prep website I'm using got it wrong?
measuring the performance of the Sprints
The only place I can relate that sentence to the scrum guide is in within the Sprint Planning section:
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.
The scrum guide is silent about how you capture that performance but definitely states that you need it as part of your sprint planning input. That is not an artifact whatsoever, but a rule.
Taking into account that the scrum guide also says:
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.
Would you say then that measuring the performance of the sprints is a mandatory part of the framework? What would be the outcome if you omit it?
Would you say then that measuring the performance of the sprints is a mandatory part of the framework? What would be the outcome if you omit it?
When you see terms like 'mandatory' in an exam question, do you think that type of question might be a trap?
If the question asked about inspecting the past Sprint in the Sprint Retrospective, and adapting the next Sprint based on that, might that lead to a better outcome?
The Scrum Guide is not a how to guide.
I think the use of the word "performance" is confusing, and it could be interpreted to mean several different things.
Here's a quote from the Scrum Guide that I feel may be relevant to the discussion:
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.
Simply put, performance measurement and monitoring is one of the references that the Scrum team uses to inspect and adapt.
The purpose is to provide transparency in the development process.
This is an ongoing activity, not a mandatory event.
I think 'Measuring Sprint Performance' could be 'Monitoring Sprint Progress' section of the scrum guide which is about forecasting from the Sprint Backlog. From that borderline angle, it can relate to the Spring Backlog which is an artifact.
"Development Team tracks this total work remaining at least every Daily Scrum to project the likelihood of achieving the Sprint Goal."
If I were you, I would get rid of that material. Not sure if that third party is the best to rely on for your exam prep.
There are only three artifacts: the product backlog, the sprint backlog and the increment. If you see any PSM I exam question that asks if anything but these three is a Scrum artifact, the answer is a resounding NO.
Given the fact that the Scrum Guide says nothing about performance measurement, it is also NOT mandatory.
Non-PSM I related: there is nothing wrong with measuring performance, provided that the Scrum Team themselves initiate this measurement. If management enforces metrics as a command and control mechanism, they are undermining self organisation. Apparently management has an idea about how someone should do their job and what the output should be. In most cases, this will trigger unwanted behaviour to please the metrics.
If this happens to my teams, I usually put a quote on the wall like "Tell me how you measure me and I will tell you how I will behave". Slightly passive agressive, I know. But I also talk to management that imposes the metrics and explain to them what the effect is.
Scrum does mention a measurement though. It should be validated whether the increment provides the expected customer value. The goal is to see if you are building the right thing and should continue doing so. It focuses on outcome, not output.
I would recommend to use the exam prep mentioned on this website. Third-party stuff can be falsly interpreted material, where you can find the exact material and theory over here.
Scrum Guide does mentions the word "performance" of the team. The Sprint Planning section part 1 has a line -
"The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team"
Past Performance of the development team is an internal team metric.
OK, so this is the typical situation where
1. No need to worry because the real exam will not have a question like that.
2. Every third-party test is only good for discovering potential blind spots. For example, the discussion we are having on this topic may help us grow our knowledge, even if we disagree with the third-party stuff:)
3. It is very common that preparation tests target random words in a text. What is the essence of Scrum? What guides the Development Team in building the increment? You do not need to learn the guide word by word, but need to understand it. So, when the past performance of the team is mentioned as an input of sprint planning, it is merely a warning no to plan with more product backlog items than you can reasonably deliver. If a scrum team does not delete its past Sprint Backlogs, the past performance is pretty much 'measured' without further actions, anyway. It is also 'past performance' if you simply remember that customising a given module for new customers takes 7-8 days.