7 common mistakes when starting with Scrum

Maarten Dalmijn
Mar 12, 2018 · 7 min read

Starting your first sprint is like starting a fire: it is much harder to start than to keep going. So what is the best way to start your first sprint?

When lighting a fire, how you place and stack the wood matters. Do it right and you can enjoy the fire with little effort,aApart from sometimes chucking a log on top. Do it wrong and the fire requires frequent attention to keep burning.

It is the same when starting with Scrum. How you start your first sprint is the foundation for next sprints. A poor start lingers and affects upcoming sprints.

I worked at 4 different companies where they started using Scrum. I introduced Scrum to eight teams at one of the companies I worked. I noticed when teams started their first sprint, they would often repeat the same mistakes as other teams.

I would like to share the 7 most common mistakes that happen when teams start their first sprint with Scrum.

1. Starting with sprint 0.

Before starting your first sprint a team member talks about ‘sprint 0’ being necessary. Sprint 0 is a special preparation sprint you need to do before you can actually get started on a real sprint.

If you were to reduce Scrum to a single rule it would be this: produce working software at the end of each sprint. Teams may use sprint 0 as an excuse to not deliver working software.

Sprint 0 establishes a dangerous precedent: it is fine to have special sprints that are different than others.

2. Neglecting to explain your first couple of sprints will be a bumpy ride.

There is no such thing as Sprint 0, but the first couple of sprints your team will struggle more than usual. The first sprint is different because it will always be more vague and messy than sprints that follow.

The same principles apply for the first sprint as any other sprint however.

3. Over-committing the first sprint.

Deciding how much work to pick up in the first sprint is tough. There are no story point estimates yet and the team does not have a velocity. How do you know how much work the team can take on?

An example of a slightly ambitious amount of load somewhere in Africa.

In their excitement most teams take on way too much work in their first sprint. During the sprint the team focuses on being busy, instead of making sure the work items wait as little as possible. Items do not get finished quickly. Everybody works in isolation instead of working together.

The better approach is to under-commit the first sprint. You will spend more time refining for next sprint than usual. Worst-case you will refine items more than one sprint ahead.

By under-committing you force your team to work together to finish items.

4. Being unaware of dependencies affecting your team.

In an ideal world, your team never depends on others who are not part of the team. As written in the Scrum guide:

“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

Guess what? I never worked with any Scrum Team that did not (sometimes) depend on other people who are not part of the team.

Some common situations I have encountered over the years:

  • DevOps are not part of the Development Team.
  • Designers work in isolation from the Development Team.
  • User acceptance testing happens after the sprint.
  • Back-end and front-end developers work in separate teams.

If you do not manage these dependencies actively, items during your sprint will get stuck.

Align your Definition of Done so your team will not get blocked by dependencies outside their realm of influence.

5. Forgetting to prepare for the second sprint.

Just finishing what you promise during the first sprint is not good enough. The Development Team needs to work together with the Product Owner to refine enough items for planning the next sprint.

Without refined items your next sprint planning will be difficult.

You might think: what is the point of estimating work you have already started working on? After the first sprint you will have a velocity you can use to plan the next sprint.

6. Failing to manage expectations of stakeholders.

It is important that you set the right expectations with your stakeholders. The first couple of sprints will be very erratic, because the team figures out their velocity and how to work well together.

Give your team the permission to suck by telling everyone your team will perform poorly in the beginning.

Failing to manage expectations will cause frustrations with your stakeholders and may even cause them to undermine your agile transformation efforts.

7. Demonstrating unfinished functionality during sprint review.

Unfortunately the sprint review is often quite political in nature. When the team fails the sprint, nobody wants be the one to tell: ”We did not finish the sprint as promised”. Even if the Scrum guide calls it a forecast nowadays and not a commitment anymore.

It is much easier to just show work in progress at the sprint review. Somebody in the team says: ”We did so many cool things, even though it is not finished we can still show it”. Fine, so you show unfinished work and everybody is happy right?

Everybody expecting the first sprint to be big success leads to failure. Creating an environment where you team has the permission to suck is essential.

The purpose of the sprint review is to make transparent what value has been delivered. This is why a clear Definition of Done is necessary to make transparent what ‘done’ means. Showing unfinished work means you are being dishonest about the value being delivered.

The beautiful Sagrada Familia in Barcelona. Perhaps the most famous example of unfinished work in the world.

Showing work that does not meet the Definition of Done is dangerous. It may create the perception your team is performing better than it is.

Imagine next sprint you end up in a slightly better, but similar, situation. Now there is a precedent to demo unfinished work. Otherwise it seems your team is performing worse than previous sprint.

Showing unfinished work protects the team from the pain of a failed sprint. But the disappointment of not finishing helps fuel the desire to do it right the next sprint. Failure is good because the people feeling the pain are in power to do something about it.

Well begun is half done

Doing the following in the first sprint sets you up for success:

  • Deliver working software at the end of each sprint. Do not use sprint 0 as it sends the signal it is okay to not deliver working software at the end of a sprint.
  • Give your team permission to suck. Make room to learn from mistakes. Make sure everyone is aware the team will initially perform poorly and that there is a new structured process for picking things up.
  • Keep your first sprint small. Over-committing creates carry-over effects in your second sprint. Under-committing, on the other hand, forces your team to work together to move things forward, instead of each team member working in isolation.
  • Scrum assumes your team to not depend on others who are not a part of the team to do their work. This is almost never true. By managing these dependencies from the first sprint you prevent your team from being blocked by factors outside the team. Align your Definition of Done with outside dependencies. A well thought-out Definition of Done can save your team a lot of frustration.
  • Use the first sprint to establish a reference. Assign story point estimates to all work done in the first and second sprints. You will have a velocity after the first sprint which you can use to plan the second.
  • Do not show unfinished functionality in sprint review. Functionality is only finished when it meets the Definition of Done. Showing actual progress is always better than the false illusion of progress. At some point reality will catch up. Presenting a failed sprint sucks, but helps encourage the team to do better next time.

HackerNoon.com

how hackers start their afternoons.

Thanks to Jean-Pierre Lambert

Maarten Dalmijn

Written by

Product Owner and Agile enthusiast. https://www.linkedin.com/in/maarten-dalmijn/

HackerNoon.com

how hackers start their afternoons.

More From Medium

More from HackerNoon.com

More from HackerNoon.com

WTF is The Blockchain?

More from HackerNoon.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade