Experience Report

Confessions of a Sprint 0

About this Publication

How do we start sprinting effectively? We all appreciate the support given by experienced individuals when we start our own Agile journey. However, when we transition to a role of guidance, how we start a new team delivering quality software every iteration, or even resetting an existing team with bad habits, is a less well-known construct. Here I intend to regale the tale of orchestrating my first Sprint 0 to reset an existing team, and the various twists and turns through Sprint 0 and onwards to our first effective review.

1. INTRODUCTION

The story begins by outlining the challenges this team faced with client engagement and delivery. I will outline the major events alongside these issues that triggered the need to plan a Sprint 0. Walking through the story of the key ceremonies we undertook as part of the Sprint 0 process will form the main part of this tale. I’ll also reflect on any activities that we did not engage in that could have eliminated some post-Sprint 0 issues and how our Sprint 0 experiences were used to inform the experience of other teams. Finally, I shall end on a high discussing the first sprint review undertaken by the team that denoted the successful transition from Sprint 0 into regular client feedback and engagement.

2. BACKGROUND

Once upon a time, in a large investment bank, a merry band of developers and their friendly neighborhood Scrum Master were struggling to find their purpose. I had transitioned into this team as a combined Scrum Master and Team Lead at the start of 2020. When I had worked in this domain previously, development teams had engaged with the Project Management Office, or PMO. The PMO group had responsibilities for eliciting business requirements, coordinating with IT on estimates, and providing regular updates to senior business stakeholders on all IT projects currently underway. Before I started on this project, business stakeholders Malcolm* and Jayne* were serving as product owners engaging with the developers directly, meaning the PMO was responsible for general updates and light touch coordination.

Initial grand promises of a strongly collaborative and engaged pair of shared product owners turned out to be a mere fantasy. By my second week, the product owner duo, Malcolm and Jayne, raised concerns that this team was not delivering the product the organization desperately needed. As a result, they ceased to attend the ceremonies, meaning the team no longer had dedicated time with either product owner to ask questions or raise concerns. To bridge the gap a couple of users were made available to direct questions to. Their insights were great, but they did not have the authority to make any decisions on the product direction.

This event marked the start of a rough few months for this team. Without dedicated time from knowledgeable product owners, the team struggled to fill the gap by delivering what they understood to be required. Although the Technical Area Lead, Simon*, and I attempted to engage and provide the direction the team desperately needed, it became clear that we could not provide a full vision of the product direction without leading it ourselves. This gap led to further concerns that the team was still not delivering the product the organization desperately needed. And so, we continued around the delivery discontent cycle with clients unhappy at the state of delivery, and the team unsure of the direction in which they needed to go. Senior stakeholders felt they still were not getting the value they needed, and the team struggled to fill the gap by delivering what they understood to be required without a common vision.

A further complication that widened this divide was the experience of the developer group. I was not the only one new to the area. Several new developers had joined the team over the last few months as well from a mixture of internal and external sources. This meant there was a high learning curve for almost half the team not only in the technology stack, but also product expertise and business knowledge.

The key event that changed the tide for this area was the introduction of Zoe*, a new Product Owner for this team. Like her predecessors Malcolm and Jayne, she possessed a strong knowledge of this domain and a mandate to provide the required authority for prioritization of capabilities. Unlike Malcolm and Jayne, she could dedicate slightly more time to the team for feature discussion, provided a single point of contact and could build and communicate a new roadmap and set of objectives to give the whole team a sense of purpose that aligned with the needs of the users.

This was no random act of good fortune. In terms of the wider department, our area was at the beginning of a journey where a set of Agile coaches were launching a campaign to establish best practices within the business area this team resided. This Sprint 0 marked the start of a wider effort to re-establish each team within their business domain. While the campaign started in the background, this team led by example as the first to go through a Sprint 0 to reset their alignment to the product vision.

At the time this was seen as a welcome change in circumstances. Nevertheless, it introduced a new set of challenges. Most notably, how are we going to work together to fulfil the high expectations of this new product vision?

3. THE SPRINT 0 STORY

Unlike the traditional justification for engaging in a Sprint 0 to set up a brand-new team, this situation is unusual. I had only ever heard stories of this technique being used to help a new team establish their product vision and ways of working. Excluding the new additions, the team had been established in some form for around one year. This exercise aimed to reset the existing team that was going through the changes in circumstances.

This was the first Sprint 0 that many of us had been involved in. Sprint 0 is defined as a short increment to set up the team for future delivery. 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!

3.1 Finding Our Feet

The initial kickoff with management highlighted early that this situation would introduce challenges. Our first meeting to determine the approach demonstrated this quite clearly. At the time it was unclear what sessions we would need for our resetting objective. When discussing duration, senior manager Bridget* boldly claimed that 30 minutes a day for a week should be more than sufficient to get this team up and running since they were already producing deliverables. The reality is that all individuals in this story, including Bridget and myself, did not understand what was involved in a Sprint 0, making it difficult to estimate the time required without further research.

As an organization, we are in the middle of an Agile transformation. Given the size of the company and the scaling efforts required, there are many internal resources designed to help educate us and support us when transforming teams. Much of our internal documentation was purposefully vague to ensure groups had the flexibility to include sessions they thought to be relevant to their situation. However, the opposing side to that is that when you are new to this concept, it’s difficult to figure out what types of forums you need and what your outcomes and deliverables should be.

It also uses language and scaling constructs common to our company that often make it difficult to determine if this is an adaptation specific to us or used industry wide. It was only after I had completed my first Sprint 0 that I found through outside research that there are resources discussing what elements are useful to include, as well as opinions on their place in Scrum due to special treatment and lack of a deliverable benefit [1].

The best resource turned out to be seeking advice from those who have already done it. I found that the best source of information turned out to be not necessarily the documentation. The experiences of our Agile Coach Jerry were great, as were those of Derrial*, a colleague from another department who took part in a similar Sprint 0 kickoff before us. He shared with me his meeting timetable, the outputs of those sessions and decks that they used to support their discussions. It is very much true that the experience of others is one of the best sources of information!

3.2 Planning the Sessions

Through the guidance of Derrial and Jerry and coordination with Zoe to understand what sessions she wished to include I became more confident in which forums the team required to generate a shared way of working with Zoe. Across the sessions we wanted 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 discuss and 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

After discussion we also decided to add business knowledge shares, conducted by Zoe. These training sessions gave an overview of the financial products the system under construction intended to capture. They also gave an insight into the typical day in the life of key users, or personas, of the software the team are building.

One item that was purposefully left off this list was dedicated Scrum training for the team. Jerry and I arranged for Zoe to attend Product Owner training available via the centralized training service. Additionally, we took Zoe through some additional material in our own time. The remaining team members were encouraged to enroll in any Agile training they felt was appropriate, with a brief overview of the Scrum ceremonies planned for the start of the ceremony calendar session. However, for any teams going through Sprint 0 that are new to Scrum, I would recommend including training meetings.

3.3 Running Sprint 0

I will be honest; I was reluctant to start arranging meetings while still planning out the content. Despite the support from Jerry and Derrial, 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 advice from Hoban*, a senior leader with experience of Sprint 0 that gave me the confidence to commit to calendar entries and prepare any required content together in parallel to running the sessions.

Despite this newfound confidence, scheduling meetings was not as straightforward for this team. The developer population was split between India and the UK. With Zoe 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. Thankfully, the notification of an analyst Inara* from the UK joining the team part-time to help with a particular initiative was timed towards the start of Sprint 0 and therefore she could easily be added to discussions in the same time slot.

The preparation work involved for each assembly also proved difficult to juggle with deliverables. Throughout the transition the developers and myself were participating in Sprint 0 discussions as well as continuing to deliver features off the existing backlog. It could have been a good idea to pause this activity given the new vision being set out by Zoe may not have aligned to these items. It may have been possible to focus on reset activities only. 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 nine business knowledge sessions were conducted by Zoe as the sessions were limited to 45 minutes to both allow for discussion as well as cover the material in digestible increments.

The team norms, or working agreement, generation proved to be of particular importance. The team were distributed across the globe and juggling personal schedule challenges due to the pandemic that needed to be accommodated. This ensured that our availability and communication preferences accommodated the commitments of all team members. 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.

In addition to these shared sessions, Zoe, Simon, 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. This tooling was being rolled out across the department to all teams. As the team was unfamiliar with this tooling, a demo was added to the communication session to show them how to use the tool.

Most forums generated the expected output. The start of each session focused on educating the entire team on what artifact we were generating together and how it related to agile practice using slides and diagrams. Using the interactive whiteboard feature in Zoom to elicit any interactions from team members made it easier to centralize their feedback in the artefacts that we shared on our common document space. One example where the use of an interactive whiteboard worked well is when building our team norms. 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. These norms are people rather than process centric.

In our case, when building the team norms together, we started with a discussion on what a working agreement was, and how it could be used to help the team establish how they want to work together. From there we then collected all items together using a whiteboard and then I took all feedback and converted it into an editable document in our shared document space that could be amended later as the team faced challenges and amended their ways of working. The team came up with some great suggestions for our working agreement, with my favorites being:

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 discussion that proved to be most challenging was the ceremony calendar sitting. This was the first where we ran out of time. Placing ceremonies in the calendar that accommodated both the earlier time zone and Zoe’s busy schedule were difficult. Another issue we faced in this meeting was that we did not have an idea of the schedule for key stakeholders that we wanted to attend the sprint review. As a result, it was taken as an offline action for Zoe to find a suitable slot and add the entry to everyone’s calendars.

3.4 Sprinting Out of the Blocks

It is difficult 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 prevent the team from making any mistakes. After running these sessions, we decided to enter our first delivery sprint in the hope that the agreed ways of working would help us eliminate any challenges we found together.

It was not smooth sailing from the start. One early issue that appeared was that of the level of bonding within the team. Despite the new team members settling in well, and communication channels being agreed to help Zoe 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, highlighting that perhaps not all were comfortable speaking up.

To be a band of heroes, you must be able to perform as a functioning machine rather than a distinct set of parts. To eliminate this problem, I took the suggestion from Coach Jerry to try helping the team get to know each other better by showing their own photo collages of what is important to them. Everyone appreciated finding out about my love of food, travel, and music. It was great to hear that I shared Kaylee*’s love of food and not her enjoyment of playing basketball! The results of this experiment were mixed as only myself and Kaylee took part in this voluntary exercise. In hindsight, engaging in team games would have served as a better tool that could fit with 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 in two key respects. Despite setting up new boards to visualize all work, developers within the team required some time to adjust to the new tooling. Over the first sprint as developers used the new tool for tracking their work, they became more comfortable updating the tool. Nevertheless, the team had to adapt their usage to improve their working practice. For example, while they initially used the notes section to keep track of individual tasks required to achieve a given story, we later switched to using the task ticket type to make the breakout more transparent.

I do not consider this adapting time to be a failing of Sprint 0, but a healthy enforcement of continuous improvement by the team. It could be easy to try and prepare for every eventuality in a Sprint 0, or opposingly to focus on just building out the product backlog and a plan for the first few sprints. Trying to cover every eventuality in Sprint 0 is impossible! Even if it was possible, it eliminates a potential learning opportunity for the team. I’m glad we tried to introduce the tooling in sprint 0, but also allow the team to experiment with the tool itself and adapt it to their preferred way of working in subsequent delivery sprints.

The second work visibility challenge was related to the appearance of unplanned work. The new metrics we were collecting highlighted the impact this was having on committed deliverables. As shown in Figure 2, for the first few sprints post-Sprint 0, the team was only completing 50% of their committed work. It was only during the Christmas period where priorities were adjusted due to developer vacation time where the team managed to over deliver, resulting in the large spike visible in Figure 2. This later normalized to completing just over the committed points.

Figure 2. Post Sprint 0 Committed vs Completed Percentage Metrics

This proved to be a frustration for Product Owner Zoe as well as the PMO function that supported her and delivery efforts across the group. The business objectives and metrics were visible to both parties as Zoe had communicated these across the PMO group as well as to other stakeholders. Opposingly the system hygiene work required to keep the systems in good maintainable condition was not transparent. In hindsight, the hygiene work should have been included in the product roadmap in addition to 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.

One obvious gap in our Sprint 0 work that could have potentially identified some of these items sooner could have been a retrospective at the end of Sprint 0. A combined retrospective for the parallel delivery and the Sprint 0 activities were carried out together. While some feedback was received on the value of the knowledge share sessions, most items raised were about the parallel delivery sprint. It is easy to leave out a dedicated retrospective for Sprint 0 as it is a preparation-focused initiative. Nevertheless, if I could do it all again, I think a dedicated Sprint 0 retrospective would have been useful for identifying and additional concerns, successes, or gaps in the team before commencing delivery sprinting.

3.5 The Biggest Hurdle

These small challenges proved to be items that could be overcome with collective team improvements. There was one significant challenge originating from our Sprint 0 that required significant work to remediate. Remember the action in the calendar formulation session for Zoe to find a suitable time slot for the sprint review? It turned out that arranging a regular recurring meeting for one of the most important Scrum ceremonies was not straightforward.

Over time Jerry and I became concerned when no session appeared in our calendars within the first couple of sprints. Our investigation discovered 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 difficult. The second issue was that of not wanting to repeat accomplishments. Zoe, the PMO office, 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. A minor third issue was concerns around the timeframe required for the session. Some thought an hour was too much time, leaning to a preference for 30 minutes to cover updates, metrics, risks, issues, and demonstrations of new features.

The most significant issue for this squad was that of accountability. For the first couple of sprints, there was a perception of an update being significant enough to communicate. Therefore, these other forums were determined to be enough. But the problem is that 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 myself 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 Bridget, Simon and the developers raised concerns that the timing of this review with a challenging sprint meant they were not comfortable presenting their results. Ultimately, it was cancelled shortly before it was scheduled to take place. However, this resulted in a missed opportunity to obtain feedback on what was delivered, as well as gain support for handling challenges the team were facing.

4. EPILOGUE: THE FIRST SPRINT REVIEW

Off the back of the cancelled sprint review, Zoe did schedule a review for the next sprint. At this point, Sprint 0 was a distant memory having been completed two months previously. The deck I created for the cancelled prior review was used as a template to showcase the metrics for the latest sprint, with Zoe and myself contributing details on sprint deliverables and captured metrics for the team. We included 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 3 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 Zoe 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 were receiving lots of questions from stakeholders on the state of their product deliverables and the team metrics. The buzz in the room meant that thirty minutes passed quickly with only half the planned content covered. Zoe 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 a point in which the efforts of setting up this squad through the Sprint 0 and initial sprints were seen to bear fruit. 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.

5. KEY LESSONS

Sprint 0 can be a great mechanism in Agile transformations not to only establish new teams, but also to reset existing ones undergoing a significant team altering event. You may have assumed that the key focus of a Sprint 0 is to generate a detailed initial backlog, plan for the first couple of sprints and decide when your ceremonies occur. I have come to realize that in fact Sprint 0 should be defined as a small segment where teams collaborate to prepare themselves for the upcoming delivery journey. In addition to the backlog and roadmap, any items that get you ready to start working together cohesively should be included. For those looking to embark on their own Sprint 0, I would recommend covering the following topics:

1. Product roadmap and initial backlog.

2. Delivery metrics and Key Performance Indicators that connect to business objectives.

3. Stakeholder identification.

4. Team bonding.

5. Working agreements.

6. Definitions of ready and done.

7. Ceremony calendar.

8. Agreement of communication and collaboration mechanisms, including work state management tooling, chat forums, conflict resolution methods and e-mail usage.

Even once you have embarked on your Sprint 0 and start delivery sprints, it is inevitable that you will find elements that you have missed. Or you will be unsure if you are ready to start delivering. It is fine to build on any Sprint 0 once you start sprinting to improve the team effectiveness. Ultimately, the only way you will really be able to know 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 completed.

6. ACKNOWLEDGEMENTS

I wish to thank Gerard (Jerry) Shea, our Agile Coach, for his guidance and support through the journey of creating my first Sprint 0. I also wish to thank my Shepherd, Courtney Shar, for all the feedback and friendly banter she has given me throughout the writing process. Finally, I wish to thank my husband, Andrew, and son Archie for welcome breaks from work and paper writing running excitedly around the living room.

REFERENCES

[1] [Scrum.org] https://www.scrum.org/resources/blog/scrum-myths-it-ok-have-sprint-0-design-sprint-hardening-sprint

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Agile2021

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now