Give 1-day sprints a try! I have and this is my feedback

Give 1-day Sprints a Try! I did and this is my Feedback

Your team will come out more awesome

Cet article est également disponible en français.

I recently facilitated a one-day sprint. What was the point of it? To teach them how to work together, at the same time, on the same thing, from start to finish:

• Work together on the design of backlog product items, and at the last possible moment
• Work together on the same product backlog item, at the same time
• Push to production as a whole team effort, especially concerning the manual non-regression testing part

The biggest difficulty lies in the diversity of skills that make up the team: each member has his own area of expertise and is naturally restricted to tasks that affect his field of expertise.

Here is my feedback on this day.

The day ended with a debriefing session, during which we wrote down most learnings.

TL;DR: it was great!

Reminding goals & rules

Once all team members arrived and after sharing pastries (us French people can’t start a proper meeting early in the day without some famous croissants), the day begins with a Q&A session followed by a reminder of the why and how of the 1-day sprint practice. Why do it? Where does the idea of ​​doing 1-day sprints come from?

Choose a topic, one and only one. It’s the only thing to do today. Everything has to be done: from the idea, from the first design elements, until it goes into production. From the start, from the real start, to the finish, the real finish.

Choosing A topic

Here we go!

The day finally really starts by defining the topic of the day.

The team digs a little in the product backlog to find a good candidate.

The team finally finds something suitable: something small while still bringing value to the user.

The team starts to discuss about the expected behavior of the change. Now it looks like that there are more things to do than it seemed at first sight.

As a facilitator I urge them to reduce the scope as much as possible to actually do everything in one day. I also remind them that the goal is to go to the bitter end, that is to put in production or at least to be ready to put in production. Optimism is in order but in doubt the team agrees with me. The team splits the backlog in order to reduce the day’s scope.

The day will end at 5 p.m. to leave enough time for a debriefing session. The team will aim to end development by 4 p.m. so that they have enough time to get the day’s release fully ready.

Design

Without transition, the team starts to design the new feature. What are the use-cases? Which behavior is expected? Which software architecture?

The magic happens. In the most natural way in the world, the whole team stays together to design the new feature.

The room is full of energy, discussions fly over the room.

There is no silo, everyone take part and the whole team designs the new feature together.

“Let’s estimate!”

Before leaving the meeting room to get back to the team’s open-space and start development, the team draws Planning Poker sets to estimate the day’s topic. I ask them why they do want to estimate. Their answers sound sketchy. It smells like Cargo Cult, habits anchored in the routine practiced for too long, now without truly understanding the reason behind.

After a quick chat, the team concludes that estimating is not that useful for this day. Relief can be felt across the room. Everyone is obviously used to estimating yet that does not make the activity enjoyable for the team.

Time spent

In the end, 20% of the 1-day sprint will be spent on this design part of the development. This amount of time is perfectly reasonable and normal. The big difference is that today this time is used upfront before working, while usually it is spread over one or several previous sprints.

By the way it will be seen by the end of the day that 20% might not be enough. Spending even more time would have been wise:

• To fully define the scope of the day’s topic,
• To be really clear about what is part of the day’s topic and what is not,
• And to split even more the day’s topic into a smaller scope.

Development

The team starts working. There is something in the air. We see discussions between front-end and back-end developers synchronizing with each other on how to define and use the API’s. They go to the Product Owner to clarify details of the scope. Some developers pair-program together and even seize this opportunity to try out TDD, or Test-Driven Development.

There is clearly something going on in the office.

The daily Scrum mistake

3 p.m. Stress is building up. The Product Owner is spending more and more time in the team’s room. It seems natural to do a daily Scrum-equivalent to gauge the situation.

At that moment it is not obvious for the team that the goal is in jeopardy. However the team kind of suffer this daily Scrum, since this impromptu meeting is not really at the team’s initiative. Some feel that they are wasting time, some very precious time given the situation.

Why did this daily Scrum happened? For the wrong reasons. It was not really the development team’s initiative but rather the Product Owner and stakeholders’, worried about how things were going on and fearing that the team could “fail” this 1-day sprint.

It is interesting to note that classic stress patterns happen despite the lack of stakes (this is only one day worth of development). The exercise makes them easy to see and to analyze.

Getting ready to release

Tick-tock, tick-tock…

The limit of 4 p.m. is blown out and there is so much tension facing the end of the sprint at 5 p.m. Who is the culprit? The build server and scripts taking too much time to run. I am told that “We are requesting more builds than usual, we are all working at the same time.”

Meanwhile the manual non-regression test plan is prepared. For the first time, the whole team will be involved to perform the tests.

I announce that only 10 minutes are left. The stress is unparalleled…

End of the sprint

It is 5 p.m.: it is the end of the sprint. The result is unambiguous: the team is still waiting for the release candidate to be deployed in staging environment, so the test phase could not even start. The team is furious thinking that they failed that close to the goal…

Then some team members announce that they started testing anyway on the local build, and that they found at least one regression. The team was actually way farther from the goal than they initially thought!

Debriefing and learnings

I then facilitated a quick retrospective: what prevented the team from successfully complete the day’s topic, and most importanting what did the team learn?

• At the beginning, in the morning, it was natural for everyone to take part in the discussion and to define the scope, to define the use-cases, to talk about architecture, and so on. All together, without trying to prepare things during the previous sprints.
• During the day some developers gave their first real try at pair-programming and TDD.
• Tooling is clearly in need of some love. At the end of the day the team’s tools would take 30 minutes to run. It could be argued that it is only due to the particular case of the 1-day sprint and that usually it is secondary. But maybe tomorrow they will have to fix quickly a critical bug in production, and in this case 30 minutes of delay will be a real problem…
• There is a lot of technical debt and doing a 1-day sprint is the perfect way to see how it slows down the team while jeopardizing its predictability: in the morning it seemed easy to successfully finish the day’s topic on time.
• Lots of feedback about how to specify the expected behaviors. In particular, should we manage error cases or not? Should we integrate it into the DoD (Definition of Done) or explain it in User Stories? As a result it seems that spending 20% of the day in the morning preparing the topic might not be enough yet.
• Working in 1-day sprints is not necessarily slower! A quick calculation compared to the team’s usual velocity makes clear that the team’s ability to deliver is very similar to the usual velocity of the team.
• Error handling pulls another string. Error management started as a purely front-end problem, but the team ended up talking about how back-end needs to manage it well, to standardize it, and to have error codes that are both meaningful and useful. In the end, it is important to realize that this kind of problem is about back-end as much as front-end.

It was definitely a great experience, a real team building event and a gold mine of learnings.

• The exercise brings to light all the problems of the team. It shows that it is not necessary to prepare topics upstream during previous sprints. Finally, it simply shows that it is possible to work together.

I highly recommend 1-day sprints!

Sources and further reading

John Cutler : why are 1-day sprints a good idea

One Day Sprints

Ron Jeffries : sprint length must be reduced up to the point where the team successfully deliver value

Small topics: Done, and Sprint Length

Liked this article? Show it!

Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.

And follow me on my blog to be notified when I publish new articles!

Thank you so much!

Give 1-day sprints a try! I have and this is my feedback was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.