Cet article est également disponible en français
There is a very bad behavior that is often present in teams that engage in a sprint with too many story points —or user stories count. Indeed, some team members might feel that they need to work overtime to reach the commitment they made in the forecast. They do shadow-velocity.
What is shadow-velocity?
Shadow-velocity is a term that came to me while writing “Scrum : The perfect day to start a sprint“. It describes when a team member (or several) does unplanned work, either after hours within the week, weekends or even during holidays.
Why shadow-velocity occurs and why should it stop?
The reason for this extra-work can vary from “wanted to start/finish a story” to “quickly fix a bug under the hood”.
Whatever, there is always one good reason to start at least.
To keep team’s velocity flat
Why? Why would the team want to have the same velocity as the sprint before? Each sprint is different. The team doesn’t work on the same tasks and they learned so much from previous sprints, it’s a whole new world!
No one —should— ask the team to keep a constant velocity from sprint to sprint. However, if they do, make sure to tell them that a sprint is unique and asking a flat velocity will hurt the product.
To compensate an incorrect forecast
If members of the team feel they need to compensate an incorrect forecast, this is an issue that needs to be addressed with the whole team, including the product owner, and perhaps even some stakeholders. The retrospective is a good time to discuss this issue, but it’s not the only moment.
Forecasts need to be adjusted when necessary. Adding or removing story points is allowed and should not be punished.
In 2011, the Scrum Guide has removed the term “commit” in favor of “forecast” in regard to the work selected for a Sprint, for a good reason.
A Sprint Backlog is complex enough that uncertainty is always present, and common sense tells us that we shouldn’t promise what we are not sure to be able to deliver. When we use the word commit, we can be easily biased towards that duty-obligation-promise way of thinking.
On the other hand, the chosen alternative “forecast” has to do with making assumptions based on reliable information and evidence. This is much closer to how an experienced Scrum Team works.
[ … ]
It is not uncommon (or unreasonable, frankly) for people on the business side to hear that the Development Team has committed to deliver a list of Product Backlog Items and take it literally.
One does not trust the team #super-munchkin
The « superhero syndrome ».
The only one capable to fix this, because …
… (s)he is the best (really).
… (s)he has all the history of this ten-years-legacy-product in mind.
… (s)he does not think someone else would do it like him/her …
Pick any answer above or add a new one.
It takes good cops to do without Batman.
We need to #kill_superheroes_in_IT #agile #Scrum— Constantin Guay (@cog_g) December 27, 2017
Then what? No one will never be able to replace this superhero. The whole product depends on him/her. What if (s)he wins the lottery one day and decide to leave right away?
This member jeopardizes the legacy and the work of the team. There is a real need to let others learn and fail, love —or hate— the product. It’s just acting as a team.
It just happens (s)he has the time to do it
Sometime the team forecast stories value too high for what they really are. In this case, when team members finish the sprint ahead of schedule and have some free time, they wonder why not fix a long-running bug, an environment, or add a small improvement to a feature?
Such action would not really add or remove velocity, it’s adjusting one or add a new task to fill the gap. But if this work goes unnoticed by others, the lack of communication may lead to problems in the future.
Create a sticky note about it, speak to the team about what you’re going to do.
You have a problem you need to face
The main problem is always the same: we, as people, need to match our model’s expectations —parents, then mentor, then boss. And this makes us do wrong things to please them.
Shadowed-velocity work goes unnoticed, uses your energy and often the feeling of accomplishment is diminished compared to official work.
The communication during theses hours is broken and can lead to more problems due to changes happening without the team knowing.
Extra work happens, and should be visible
How a Scrum Master can help the team to reveal and avoid shadow-velocity?
- Look for commits done out of business hours or holidays
- Try some filters in your product management tool to extract tasks completed outside of business hours
- Be attentive, especially during the daily scrum, that every team member is assigned on one or several tasks
- Ask. Ask at the end of the sprint, who worked on unplanned tasks and why
Please share your experience of shadow-velocity and how it impacted your product.