Resetting a Struggling Scrum Team Using Sprint 0

Change is an inevitable part of the software development process for any individual working in IT today. Responding to changing product direction is one of the key principles we follow as agilists. In addition to providing small changes to our course as we discover new information, we must also be prepared to reset our course if required to eliminate our bad habits. When stuck in a rut, how do we reset in such a way that we set ourselves up for delivering value again?

Unlike the traditional justification for engaging in a Sprint 0 to set up a brand-new team, I found myself in the unusual situation of using Sprint 0 to reset an existing team which was struggling to deliver. Initially, I assumed that setting out the product vision and an initial plan for the first few sprints would be sufficient. However, as you will come to see through this journey, there is more to setting up a team for successful delivery than just a product backlog and roadmap!

Here I regale the tale of how we used Sprint 0 realign or a project course for a struggling team to align to a new product vision. I’ll cover the background for using a Sprint 0 to reset this team and the sessions we used in our reset process. Furthermore, I’ll reflect on the elements that should have been included in this reset exercise. I’ll share the key lessons we learned along the way, including the importance of team and management support, and the best practices when running Sprint 0 sessions. Finally, I will also reflect on how we determined the success of Sprint 0, and how it’s difficult to measure whether you are sailing on the correct heading until you start to deliver as a team. 

Background

This story begins with a group of developers and their friendly neighbourhood Scrum Master who were struggling to provide business value. These challenges stemmed from three primary factors: 

1. The first problem concerned the state of product owner engagement. For some time, business stakeholders Ted* and Marshall*, whose names have been changed, served as active product owners. They regularly provided clarifications and feedback to developers directly in the daily stand ups. But by my second week in the team, this duo raised concerns to IT management that the team was not delivering the product the organization desperately needed and stepped back from the project.
2. Several new developers joined the team over the last few months. These individuals struggled with learning not only the technology stack, but also product and business knowledge.
3. The introduction of Robin*, a new product owner to replace Ted and Marshall, provided a new roadmap and set of objectives that the team had to realign to. Her arrival meant we had to figure out how we were going to work together to fulfil the high expectations of this new product vision.

Preparing Sprint 0

The list of sessions was generated in coordination with Robin, Jerry, and technical leader Barney*, based on the experiences of Jerry the Agile coach, and Brad*, a colleague in another part of the organisation who recently went through his first Sprint 0. Although unclear at the time, I believe that some of Jerry’s recommendations also stemmed from an Agile Maturity Assessment, using our internal maturity model, that was completed for this team just before Jerry joined our area. 

We agreed to cover the following topics:

1. Kick off, roadmap overview and communication of the product scope of the team
2. Team norms or working agreement generation
3. Definitions of ready formulation
4. Building of our definition of done
5. Ceremony calendar
6. Tooling session to agree which software to use in our daily work for story capture, work management and general communication
7. Sprint planning for the first sprint, including story estimation, breakdown, and commitment
8. Business knowledge sharing sessions where Robin gave an overview of the financial instruments the system under construction intended to capture
9. Stakeholder analysis session where Robin presented the personas of key users of the product and explained their daily responsibilities

One item that was purposefully left off this list was dedicated Scrum training for the team. Due to the team being reset, all individuals had experience in practicing Scrum. Or, in the case of the product owner Robin, had taken part in Agile training prior to entering Sprint 0.

The Sprint 0 Story

Running Sprint 0

I will be honest; I was reluctant to start arranging meetings while still planning out the content. Despite support from Jerry and Brad, it was still not quite clear whether I had all the elements required to ensure the team could start sprinting effectively once we completed Sprint 0. It was the wise words of senior leader Hammond*, that the best way to learn about Sprint 0 is to go through it yourself; that gave me the confidence to commit to calendar entries and prepare any required content together in parallel to running the sessions. It helped me realise that my Sprint 0 plan, like any product roadmap in software development, could also change.

Throughout the transition, the developers and I were participating in Sprint 0 discussions as well as continuing to deliver features off the existing backlog. Initially I planned for a single one-hour session per topic, plus backlog refinement and planning sessions for the first sprint. We had 1-2 sessions in a single day, with each session being 45 minutes to one hour in duration. The main reason for this was down to the distributed nature of the team. The developer population was split between India and the UK. With Robin being based in North America, that meant we had a short overlap of a couple of hours each day in which to host any shared Sprint 0 activities. 

The preparation work involved for each assembly also proved difficult to juggle with deliverables both in the sprints preceding Sprint 0 and throughout the named sprint itself. I found the additional preparation time for Sprint 0 challenging to juggle with my existing dual role as Scrum Master and tech lead. It may be obvious to see the efforts I was exerting to prepare the materials, arrange the sessions in calendars and facilitate some of the sessions. Nevertheless, Jerry and I were also assisting Robin in building out the initial backlog of stories, generation of the KPIs for the product, and providing general coaching and guidance on Scrum best practices. Furthermore, Robin, Barney, Jerry, and I were working in the background to set up the agreed tooling for housing our stories and tracking our work to align with the new system, whose use was being mandated from a department level. And that was before you factored in that we were arranging this Sprint 0 while working from home in 2020!

Throughout the transition, the developers and I were participating in Sprint 0 discussions as well as continuing to deliver features off the existing backlog. Due to holidays through that time, some weeks were lighter than others as we wanted everyone present in sessions to elicit their feedback. Including the days where we had a couple of sessions, Sprint 0 worked out at an average of five hours per week, or 12.5% of the traditional 40 hour working week.  It could have been a good idea to pause the parallel development work and focus on resetting, given that the new vision being set out by Robin may not have aligned to these items. However, with the team being distributed across three time zones, there would most likely have been idle time for the developers if they did not continue to work on delivering features in parallel.

Figure 1. Sprint 0 Session Calendar

The final calendar of sessions, along with the purpose of each meeting, is presented in Figure 1. It is important to note that 9 business knowledge sessions were conducted by Robin. These sessions were limited to 45 minutes to both allow for discussions as well as to cover the material in digestible increments. Since these sessions often occurred on the same day as a workshop, we also had a break of at least 15 minutes between these sessions to allow people to digest the content and grab a cup of tea. In our bi-weekly retrospectives, the team was particularly positive about the usefulness of these sessions and seemed to enjoy learning more about the business domain that this tool resided within.

The team norms- or working agreement- generation proved to be of particular importance. In a prior retrospective,team norms were mentioned by the team as being required to make their availability clear to the entire team. The team was distributed across the globe and juggling personal schedule challenges due to the pandemic that needed to be accommodated. Providing a new set of norms at this point was well received in the retrospective after the generation session, as it ensured that team availability and communication preferences were considered. 

The format of the team norms generation session showcases a typical example of the format many of these workshops would take. We started with a discussion on what a working agreement was, using slides, and reinforced how these principles not only related to agile practice, but also how they could be used to help the team establish how they want to work together. For those unfamiliar with the term, team norms, or working agreements, are the set of defining principles that govern how we want to work together as people.

Once the relevant concepts were explained, we collected any interactions from team members using the interactive whiteboard feature in Zoom. After the session I took all feedback and converted it into an editable document in our shared document space that could be amended later. This ensured that the team could amend their ways of working going forward. 

The team came up with some great suggestions for our working agreement. My favourites were:

1. Everyone has an equal voice and equally valuable contribution
2. We will value each other as people beyond just our work
3. Be transparent with any priorities, barriers, or time expectations
4. Avoid regular interrupted blocks to encourage developer flow

The definitions of ready and done were also important for establishing how we wanted to work together. Due to the related nature of these artefacts, it was initially decided that these would be built together as part of a single discussion. This plan changed when we ran out of time in the combined session, leading to an additional meeting being scheduled for the next day. These sessions also received positive feedback in our regular retrospectives. It helped the developers understand that development responsibility for a given feature didn’t just stop when the item was deployed to the user testing environment, and that Robin considered it done when in production. Initially I was concerned that, given Robin’s experience and client status, the developers would blindly accept her definitions. Thankfully, Robin and the engineers in the team were able to reach an agreement on the level of detail required for a story to be ready to start working on, and to be ready for testing by users prior to release. For this reason, we had definitions of ready and done that covered a couple of states, including the final deployment to production as being complete.

I would consider the tooling session we conducted to be a unique construct in this transformation. Due to the department mandated move to a new work management tool, this session focused on demonstrating the features of this tool and allowing the team to raise any concerns with its usage. The team was fine with the general principles of the tool, and particularly liked the ability to tie back individual stories to the high-level business objective. However, the view was mixed as they also raised concerns about the generation of our change request tickets, which still relied on the old tool. 

The discussion that proved to be most challenging and that in fact didn’t generate the desired outcome, was where the team generated their ceremony calendar. This was the first time that we ran out of time. After educating the entire team on the purpose of the different ceremonies, Jerry and I worked with the group to figure out when each ceremony would take place, while considering the time zone and personal commitments of the team. We often found that Robin, or another team member, would be reluctant to put forward availability for some ceremonies. This would cause them to attempt to either remove it from the schedule or dedicate less time to longer ceremonies such as the retrospective or sprint review. This resulted in no committed time slot for the sprint review. As a result, it was taken as an offline action for Robin to find a suitable slot and add the calendar entry to everyone’s calendars.

Sprinting out of the Blocks

It is hard to determine in Sprint 0 if you are done. There is a balance to strike between performing enough upfront planning and agreement to provide clarity and comfort, and taking significant time away from delivery to plan for every eventuality that could appear in the sprints that follow Sprint 0. After running these sessions, we entered our first delivery sprint in the hopes that the agreed ways of working would help us eliminate any challenges we found together. However, we encountered a few rocks that we had to navigate around on our path to quieter seas.

One early issue that surfaced was that of the level of bonding within the team. Despite the new team members settling in well, and communication channels being agreed upon to help Robin and the others collaborate, it became clear that the developer group needed to build trust to work effectively. Silence was a big part of many planning and refinement ceremonies. This was not a team of strong extroverts, and I had concerns that the team was not comfortable speaking up.

To eliminate this problem, coach Jerry suggested sharing photo collages to help team members learn a bit more about each other. The results of this experiment were mixed, as only Nora* and I shared collages, which revealed a common passion for food. At the time, others seemed to enjoy our collages, but disappointingly didn’t follow suit. One team member Cindy* expressed enthusiasm for the task, but stated she had a lack of time to dig through her photos outside of working hours. I could certainly understand that it was a tough task to fit in when you are busy. But this sharing experience did leave me feeling rather vulnerable. In hindsight, engaging in team games would have served as a better tool that could enforce collective participation, fit in with our schedules, require less upfront effort to arrange, and be compatible with continued remote working during the pandemic.

Visibility of work became a second challenge for the team. Despite setting up new boards to visualize all work, developers initially struggled to visualise the state of underlying tasks using the new tooling. In a sprint retrospective, a couple of sprints after Sprint 0, team members voiced concerns that using the notes section for communicating the task breakdown made it difficult to identify what work was outstanding on a given story. Specifically, they didn’t believe this approach provided sufficient visibility as to whether an individual task was complete, in progress or blocked. Therefore, they decided in the sprint retrospective to adapt their usage to use the task ticket type instead.

I do not consider this adapting time to be the failing of Sprint 0, but a healthy enforcement of continuous improvement by the team. Trying to cover every eventuality in Sprint 0 is impossible! Even if it were possible, it eliminates a potential learning opportunity for the team. I’m glad we tried to introduce the tooling in Sprint 0, but also allowed the team to experiment and adapt their way of working within the first few delivery sprints.

Another challenge we encountered related to the appearance of unplanned work. The new metrics we were collecting highlighted the impact this was having on committed deliverables. In the first few sprints post-Sprint 0, the team was only completing 50% of their committed work, as some urgent items such as production support issues, hygiene items or ad hoc queries would appear that developers would immediately pick up without communicating to the product owner, much to Robin’s frustration.

The business objectives and metrics were visible to everyone, as Robin had communicated these to all stakeholders. But these other work items were not. In hindsight, the hygiene work should have been included in the product roadmap alongside the shiny new features. The remediation required in this case was to enter the hygiene items into the tooling and put forward IT focused recommendations for a hygiene roadmap for the following year to ensure all parties were aware of all work types that required ongoing prioritization. For any unplanned items that appeared, the team were encouraged to raise a ticket onto the board to ensure it was visible for all to see.

One obvious gap in our Sprint 0 work that could have identified some of these items sooner was a separate retrospective at the end of Sprint 0. A single retrospective was used to cover the parallel delivery experiences and the Sprint 0 activities. While some feedback was received on the value of the knowledge share sessions, most items raised were about the parallel delivery sprint. If I could do it all again, I think a dedicated Sprint 0 retrospective would have been useful for identifying concerns and successes in the team before commencing delivery sprinting.

The Biggest Hurdle

These small challenges proved to be minor hiccups compared to one significant challenge that we faced in our delivery sprints. Remember the action in the calendar formulation session for Robin to find a suitable time slot for the sprint review? Unfortunately, arranging a regular recurring review was not straightforward. 

Over time, Jerry and I became concerned when no session appeared in our calendars within the first couple of sprints. While I imagine Jerry gave a couple of subtle nudges to Robin, I wanted to give the benefit of the doubt and give Robin the space to settle into the swing of her new responsibilities. Our investigation revealed several reasons for the session not having been scheduled. The first was the simple difficulty of scheduling, as the busy schedule of many interested stakeholders made finding a regular slot challenging. The second issue was that of avoiding repeatingaccomplishments. Robin, the department Project Management function, and IT senior management were all updating the same senior stakeholders on various initiatives across the entire business domain in various senior management forums and steering committees.

The ultimate issue for this squad was that of accountability. For the first couple of sprints, there was the perception that updates were significant enough to communicate. Therefore, these other forums were determined to be enough. But the developer population of the team were not present in those sessions, meaning they did not receive any direct feedback on their work.

To address this issue, Jerry and I agreed to add a review to the calendar for the current sprint to introduce the required feedback point. Yet despite the notice and preparation, on the day of the scheduled review a senior manager Lily*, Barney, and the developers raised concerns that the timing of this review with a challenging sprint meant they were not comfortable presenting their results. It was cancelled shortly before it was scheduled to take place. This resulted in a missed opportunity to obtain feedback on what was delivered, as well as gain support for handling challenges the team was facing. 

Determining Success: the First Sprint Review

Off the back of the cancelled sprint review, Robin scheduled a review for the next sprint. At this point, Sprint 0 was a distant memory having been completed two months prior. The deck I created for the cancelled prior review was used as a template to showcase the metrics for the latest sprint, with Robin and myself contributing details on sprint deliverables and capturing metrics for the team. In addition to placeholder slides to represent the demos from developers, we included a status update of accomplishments and the delivery metrics that we agreed to capture within our Sprint 0 metrics session. The key ones were:

1. Committed vs completed percentage
2. Velocity
3. Average velocity of the previous three sprints
4. Number of new defects raised
5. Total available developer hours

These metrics were selected to ensure all parties could appreciate the team’s progress. They were reported alongside key performance indicators that aligned to the business objectives outlined by Robin in the new product vision. We also included placeholders for the elements the team wanted to showcase, which had been collectively agreed in a checkpoint a few days before the review. 

The energy in this session was fantastic. Within this 30-minute session, the team was receiving lots of questions from stakeholders on the state of their product deliverables and the team metrics. The buzz in the room meant that the 30minutes passed quickly, with only half of the planned content having been covered. Robin scheduled a second session the next day due to the large number of questions and discussions happening. It was great to see such strong engagement. It was also immensely satisfying to dispel the myth among the group that engagement would be low.

This proved to be the point in which the efforts of resetting this squad through the Sprint 0 and initial sprints was seen to bear fruit. To date, the team continues to hold sprint reviews at the end of each sprint, with regular attendance from stakeholders. The goal of any Sprint 0 is to prepare the team for effective delivery. Sprint reviews are a key ceremony for determining team delivery effectiveness. Determining the success of any Sprint 0 may not come for some time as the team continues to grow and learn how to work together effectively.

Key Lessons

Sprint 0 can be a great mechanism in Agile transformations to reset existing teams which are not delivering value, exhibiting a lack of accountability, or struggling with direct collaboration with customers. In our case, the team faced all of these issues. I’ve found that these problems can manifest in the following ways:

1. The team is exposed to a new or significantly altered product roadmap
2. They are seconded to work on a new product altogether
3. The team has experienced a high degree of staff turnover
4. A new product owner enters the scene

In your own situation it might not be clear what issues need to be addressed. Or there may be disagreement on whether the team has any problems that need fixing at all. When it comes to exercising agility in practice, the perspectives of a practitioner such as myself, an Agile coach, and a developer working in the trenches, may differ. Use the principles of the manifesto to evaluate interactions and reflect on the potential problems with the team. If you are struggling to identify the issues and symptoms, consider using evaluation techniques such as an Agile Maturity Model, or even the Zombie Scrum Symptom Checker.

Even once you have identified your situation, it is important to have the support from senior management and the team itself to start Sprint 0. Ensure the team has their say on what sessions and issues they feel need addressing in Sprint 0. In this story we gave plenty of space for discussion in sessions and used retrospective feedback to discover any missing themes. In hindsight, giving the developers an opportunity to propose what sessions they would like to include could have been helpful.

I have come to realize that Sprint 0 should be defined as a small segment of time where a team prepares for the upcoming delivery journey. For your given situation, consider adding the sessions denoted below by a ➕. Any ❌ marked sessions are considered optional. Also, feel free to add other sessions you feel appropriate to help the team during Sprint 0, just as we did with our Tooling Demo.

Even once you have started delivering again, it is inevitable that you will find elements that you missed from Sprint 0. Or you will be unsure if you are ready to restart delivery efforts. It is fine to build on Sprint 0 once you start sprinting, as you encounter issues.  Nevertheless, the only way you will really be able to know if you are sprinting effectively, and with accountability, is when you have your first successful review with relevant stakeholders, which will be after Sprint 0 has been completed.

About the Author

Carly Richmond is a senior UI engineer and passionate agilist working at Morgan Stanley. When she is not working on building financial systems, she contributes her thoughts on agility, UI, UX and software development on her personal blog and through public speaking. She also loves cooking, photography and drinking copious amounts of tea.