How to avoid Scrum becoming a feature factory

You may be familiar with a sprint. Perhaps your team already works in sprints.

But what is a sprint? The Scrum Guide explains:

[Sprints] are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

The teams I’ve worked with decided to work within a sprint length of either 1 week or 2 weeks.

1 week gives a faster feedback loop, but a lot of feature development work is hard to complete inside a week. Also, per-sprint activities such as planning, the retrospective, and the review come around quite quickly.

A 2 week sprint works quite well, except it can feel a bit slow-paced if there are issues with the process that only get raised at the retro.

Scrum is incomplete

By definition, the Scrum framework is purposefully incomplete. However, in The Disastrous Impact of Framing Scrum as an Incomplete Framework, Willem-Jan Ageling makes the following argument:

The statement about incompleteness does not refer to processes AROUND the framework. As a framework to address complex problems, Scrum IS complete.

Teams may thrive with Scrum and Scrum alone. However, for many teams, the processes around Scrum are an important part of success.

The downsides of Scrum in isolation

A team can feel like a feature factory if you use Scrum on its own.

The pace of Scrum can feel relentless. One sprint leads to another, with no gaps, and no letting up.

If a new product team forms next week and they kick off Sprint 1, do they keep working towards Sprint 10, Sprint 50, Sprint 100 and on and on past there?

Using the analogy of a runner – you can only sprint for so long. A lot of sprints is more like a marathon.

Deadlines and stakeholders

Perhaps if we could be left alone to work on the product, Scrum would be enough.

But stakeholders exist. And many of them want to know when they will see a feature that matters to them.

Certain types of work may span multiple sprints. Or you may have deadlines, such as for a legal requirement, or a project to migrate a client’s data to your platform.

It may be possible to shield the product team from this type of thing. But the product owner will still need to manage expectations.

Talk in sprints, not dates

If there’s a story you want the team to focus on in the next sprint, get stakeholders used to the idea of it being “a focus for the next sprint”.

Internally, you can look at the sprint end date to see when things will make it into the product – if your Definition of Done includes stories making it to production.

Aim to split implementation teams from product development teams

When your company is small, team members will probably do lots of different things to help get the work done.

As you scale, you may find it helpful to view implementation as a distinct – but related – role from product development.

Implementation and migration – setting up clients on a platform – is more of a fixed-length project that’s likely to include some governance, steering, and target dates.

Product development is an ongoing activity.

Using the concept of stream-aligned teams outlined by Team Topologies, you could have an implementation team alongside your product teams.

However, they shouldn’t be project teams assigned to a single client’s implementation work, and disbanded afterwards. The team will do a much better job if they can “own and hone” the process over time.

Map objectives to sprint goals

Let’s set implementation aside. For a product development team, you can use Scrum so long as you set sensible sprint goals, and don’t treat each sprint as “do all these unrelated pieces of work”.

Setting sprint goals is easier if you take them step by step as follows:

  1. Set company objectives, and key requirements (OKRs)
  2. Set sprint goals that map back to your OKRs
  3. Use this to help the team understand why the sprint matters
  4. Tie all stories in the sprint – or as many as possible – back to OKRs

In summary

Scrum is a great starting point – but it’s not the end of the story. Keep implementation separate from product development – and use OKRs to set sensible sprint goals.

Photo by Candra Winata on Unsplash