There's been a lot written about what agile development and scrum should do for a team. After a team has been maturing for some time, it's easy to become blind and
insensitive to phenomena that hinder its effectiveness and restrict its potential. Let's
call them “scrum smells”.
Some teams are just starting with scrum adoption while others are moderately matured or even
experienced in it. Each level brings with it its own smells and scents. This series will focus
on both basic and advanced challenges that scrum teams commonly encounter. Today, we’ll talk
about the problem of irregular releases.
Inability to regularly provide releasable versions
One of the basic scrum principles is being able to provide a potentially releasable product
increment as a result of each sprint's effort. I personally believe this is one of the most
valuable and underrated benefits of the whole scrum world. Scrum says that at the end of each
sprint, the development team should produce a piece of software which the product owner can then immediately release and put to productive us, if he so chooses. That means that the software needs
to be working, regression-free and without any work-in-progress stuff. Everyone on the team
needs to have the feeling that there is no debt—be it technical or functional.
In real life, however, the production builds are provided quite randomly. Every scrum team has gone through this. At the end of the sprint the team would like to provide a final version, but there
are incomplete features or regressions severe enough that this version can not be put out for
productive use. So in the subsequent sprint the team attempts to fix the bugs, but continues
developing new features in parallel, which introduces a new source of potential problems and
uncertainty. Days and sprints go by and there is always something to be fixed in the current
This vicious cycle pressures the product owner to finally release
everything that's been implemented so far. There's the always present “almost there” syndrome,
the eluding moment of problem-free release. The product owner gets nervous and it's tempting to
try to sneak one more “important” thing to the sprint, because god knows when the next release will take place. Long time-to-market is a reality. So-called hardening or
stabilisation sprints occur, where teams just try to fix the product into a usable state.
Aside from the inevitable demotivation and pressure that arise, this also causes problems with planning
and transparency. You never know where you truly are until you have no work left on the already
developed backlog items.
Preparing the ground
So how to increase the chance of regular end-of-the-sprint potentially releasable versions
actually happening? This is partially about a shift in mindset. Being able to provide a working,
debt-free, done software increment must be a top priority for the team during the sprint and all
activities need to focus on this one goal.
It all begins with the backlog refinement. Backlog items must be broken down to pieces as small
as possible in order to give the team a high degree of maneuverability during planning. Oftentimes
creating really atomic user stories is necessary—that means stripping the user story to the very
core of the user's needs and solving it with the most straightforward approach. All the rest
just becomes another backlog item, prioritised independently. Keeping the items too big or just
being too optimistic about keeping some “easy to do” nice-to-have things attached to the core
user story's essence is just naivety, frequently combined with a degree of convenience.
Then, at sprint planning, the team creates a strategy to steer the risk of discovering a severe
problem shortly before the end of sprint with too little time to actually solve it. It helps to
start the sprint with the riskiest features first and strive to start testing even separate
parts of them as early as possible. This way there's a greater understanding of how much work
there is really left to be done. Low risk items (like simple text changes or UI adjustments) can
be left for later into the sprint.
The development team must not plan too much work, hoping that this time “we will manage”. The
team must, based on past experience, realistically anticipate extra unexpected work even on
“safe” backlog items.
And of course there is the well-known Definition of Done. Each team member must understand what
it takes for an item to be considered done and everyone must understand it in the same way. What
is on the DoD checklist? Well, that depends on the particular team, product and technologies
being used. But if a team agrees, that DoD of each item consists of code to be written, unit tests or
automated tests, documentation, code review, end-to-end test and anything else needed. Nobody
can claim an item done until all this work has been done. This helps to create a common standard
for quality and for complexity estimates. Strictly adhering to it reduces the risk of debt
accumulation. Missing or unused DoD creates a fertile ground for debts and makes planning almost
Day-to-day activities and decisions
Frequent end-to-end testing during a sprint is absolutely vital. It is a dangerous illusion to create a
single version one day before the sprint's end, test it and expect that all is going to be fine.
That's not planning, that's gambling.
To enable this, new builds need to be created as often as possible, even several times a day.
CI/CD pipelines are a must. TDD helps a lot. Automated regression tests are a must. Basically
automating as much of the manual hassle as possible removes the reasons why teams usually avoid
making builds regularly. This investment into automation is usually well worth it in the long
Adding feature switches (or flags) help. If it's evident that the team is not
going to be able finish a certain backlog item (i.e. fulfill the DoD), it is “switched off” and
it doesn’t interfere with the rest of the software.
The team must also understand that one done and delivered backlog item is worth far more than ten
items in progress. The daily scrum is an ideal time for the team to evaluate the sprint
backlog's progress and mutually collaborate on pushing in-progress items closer to a “done” state
as quickly as possible. Team needs to learn to constantly re-evaluate where everyone's present effort lies and decide if there is something more valuable to concentrate on.
All sprint backlog items are the whole team's job, not individual assignments. It is all about
constant re-evaluation as to where to invest the day's efforts in order to maximise the chance of
achieving debt-free software at the sprint's end.
When a sprint backlog item gets risky and it seems there's not enough time left in the sprint,
the team needs to decide whether it wants to invest more energy in it (to increase the chance of
getting it done, e.g. putting more developers onto it) or to stop working on it altogether and
focus on another item that has a real chance of getting done. Decisions to drop a
sprint backlog item must be consulted with the product owner.
For more about strategies to achieve regular releases, please check out the follow up “Scrum
Smells pt. 2” post for more details.