Devops for Growth

The 6 signs that your beautiful velocity growth trajectory may just be bad data:

Velocity always increases – Even the highest-performing Scrum teams suffer setbacks or encounter new impediments. In general, scrum teams that set challenging goals should expect to fail about 20% of their sprints, meaning that velocity should decline from the previous sprint about the same percent of time (if you are using “yesterday’s weather” to pull stories into the sprint). If your team has been through a dozen sprints without a single backslide in velocity, it suggests that stately upward trend is being managed more deliberately than it should.
Inexplicable Acceleration – Velocity can go up in short bursts for no particular reason, but it is difficult to sustain structural velocity improvement without systematically removing team impediments. So if a team’s velocity has been increasing consistently but they can’t point to specific impediments that they have removed, that is a red flag that the acceleration may not be real. At best, the team is not conducting healthy process experiments to deliver repeatable and sustainable acceleration. At worst, they may be undermining the meaningfulness of their velocity.
The same story now receives a higher point estimation than it used to – This is the definition of “point inflation” that opponents of measuring velocity in points are always pointing to. In practice, we rarely see egregious cases of point inflation where the exact same story that was 3 points in a previous sprint is now 5 points in the current one. Instead, we typically encounter more nuanced forms of inflation, such as when an additional quality check is added to correct for past issues and points are added to complete this additional work. The amount of effort needed to complete the work may have increased, but the amount of output has not, so these added points represent a subtle form of point inflation.
Backlog stuffing with “filler stories” – Teams that are striving to increase velocity often become obsessed with ensuring that everything they do is reflected in the backlog. In general, you don’t want to do tons of off-backlog work and do want to stay focused on completing the goals of the sprint. However, some level of housekeeping and team hygiene work is a natural part of the group process. If including these items in the backlog was always a team norm…that is fine. If that wasn’t always the norm, then including these filler stories with associated points gives the false impression that the team is accelerating when it is not actually producing more output.
Lots of separate minimum-sized stories – We often say that smaller user stories are better, and that ultimately teams should strive to work with uniformly small stories in the sprint. This is a great goal, but it can be taken too far. If work is broken into many stories that are smaller than the smallest sizing increment used by the team (“xs”, “1-point”, “Chihuahua”, etc.) then the rounding error of adding all these fractional stories together starts to exert a strong upward influence on velocity. If these precisely divided stories are still good user stories reflecting incremental functionality, then it is time to reset your reference story to accommodate smaller divisions. More often than not, however, these tiny stories are really tasks and are hurting the team’s ability to work together to produce quality product.
Excessive “normalization” of velocity – Tracking team strength in each sprint is helpful for knowing the context the team is operating within. There are a number of compelling reasons to apply a lightweight level of normalization to a team’s raw velocity number to get a better predictor of actual team output: it provides a more stable measure of output in the face of major illness, vacations, family leave and other significant shifts in team capacity. However, it also introduces one more lever that can artificially increase apparent velocity, so teams need to be careful to only reserve normalization adjustments for major capacity impacts, and not try to adjust for every perceived shift in team strength. If you notice that the team has not been at full capacity for a long time, it is time to questioning if over-normalization may be occurring.

Breaking through impediments

I have been in a few organizations where leaders say, “we aren’t getting any impediments.” That may be due to a few factors like teams being afraid to raise issues (Fear to Speak) or, prior situations when leaders have pushed back and said, “This isn’t an impediment. You can deal with this.” The last one is interesting. Why would teams raise issues that leaders don’t think are really a problem? How can we improve this communication?

We have come up with a way to frame these impediments that allows teams to choose their own destiny and become more empowered while removing leadership as a bottleneck.

The team can develop the Product Backlog according to a sequence that suggests an ordering for the patterns it comprises. The team can weave this sequence together with the Value Stream Sequence to elaborate those steps pertinent to developing the backlog itself. What follows is a typical sequence for starting up and maintaining a Product Backlog. Individual products may find other orderings equally useful: inspect and adapt.

§ 50 ROI-Ordered Backlog.
Normally the Product Owner orders the Product Backlog to achieve the highest ROI based on current knowledge, with the goal being the Greatest Value. The initial backlog comprises a list of Sprint Goals, each designed to characterize a single release in a sequence of Regular Product Increments.
§ 51 High Value First.
Alternatively the organization can choose to work with a fixed-scope, fixed-cost client to take advantage of approaches like Change for Free and Money for Nothing.
§ 55 Product Backlog Item.
The Product Owner, perhaps with the help of the rest of the Scrum Team, breaks down the envisioned Product Increments into Product Backlog Items (PBIs).
§ 56 Information Radiator.
The team posts the backlog visibly, both for its own reference and to inform other stakeholders.
§ 59 Granularity Gradient.
As part of breaking down the backlog, the Product Owner and the Development Team reduce the PBIs near the top of the backlog to Small Items, leaving later PBIs intact.
§ 63 Enabling Specification.
The Product Owner ensures that the Development Team members perfectly understand each PBI scheduled for the next Sprint.
§ 64 Refined Product Backlog.
The Product Owner and the Development Team meet regularly to ensure the Product Backlog stays up-to-date.
§ 65 Definition of Ready.
Right before the Production Episode, at Sprint Planning, the Product Owner and the Development Team together ensure the Product Backlog is ordered properly with respect to dependencies and market considerations, and developers estimate every imminent PBI. At Sprint Planning, the Development Team pulls Ready items from the top of the Product Backlog to achieve the Sprint Goal. These PBIs will drive their Production Episode work plan.

Jeff Sutherland describes a project language that he believes can get teams off to a good start, and which help make even the best teams even better. These patterns unfold over time as a sequence that the team follows to improve its Scrum team, One Step at a Time.

Angel Medinilla advises on hiring and evolving a great Scrum master along with resources on psychology, coaching, motivational science, communication skills, corporate culture or change management.

As an organization introduces Scrum, it might introduce these elements one at a time, as is the usual practice for patterns. The roadmap for introducing patterns one at a time is called a sequence. Here is a typical or canonical sequence by which these patterns fit together to introduce Scrum in a development effort. This is probably the minimal set of patterns which together could be called Scrum.