Looking for:
Sprint zero activities

When you do this activitirs is a great test to see if the Sprint length works for you and also a great test of your planning process — were you able to achieve what you sprint zero activities planned? About this Publication.
Motivation for Sprint Zero in a software project.The Concept and Execution of Sprint Zero — Clearly Agile
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:. The discussion that proved to be most challenging was the ceremony calendar sitting.
This was the first where we ran out of time. 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.
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.
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. 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.
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. 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. 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. 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:. 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 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. 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:. 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.
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. She specialises in frontend web development and agility. She is an Agile evangelist, UI enthusiast and regular blogger on Medium and her personal blog. When she is not building financial software, Carly enjoys cooking, photography, and drinking many cups of tea!
Download PDF. Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously. It does not correspond to any user ID in the web application and does not store any personally identifiable information.
It ensures visitor browsing security by preventing cross-site request forgery. The cookie is used to store the user consent for the cookies in the category “Analytics”. The cookie is used to store the user consent for the cookies in the category “Other. The cookies is used to store the user consent for the cookies in the category “Necessary”.
The cookie is used to store the user consent for the cookies in the category “Performance”. It is used to store the cookies allowed by the logged-in users and the visitors of the website. General purpose platform session cookies that are used to maintain users’ state across page requests.
The cookie is used to store and identify a users’ unique session ID for the purpose of managing user session on the website. The cookie is a session cookies and is deleted when all the browser windows are closed. The cookie is used to manage user memberships. It does not store any personal data. Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
This cookie is essential for the website to play video functionality. The cookie collects statistical information like how many times the video is displayed and what settings are used for playback. The purpose of the cookie is to enable LinkedIn functionalities on the page. Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
These cookies are used to collect information about how you use our website. The information collected includes number of visitors, pages visited and time spent on the website. The information is collected by Google Analytics in aggregated and anonymous form, and we use the data to help us make improvements to the website. YSC session This cookies is set by Youtube and is used to track the views of embedded videos.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc. The cookie is used to calculate visitor, session, campaign data and keep track of site usage for the site’s analytics report.
The cookies store information anonymously and assign a randomly generated number to identify unique visitors. The cookie is used to store information of how visitors use a website and helps in creating an analytics report of how the website is doing. The data collected including the number visitors, the source where they have come from, and the pages visted in an anonymous form. This cookie is used to sync with partner systems to identify the users. This cookie contains partner user IDs and last successful match time.
S 1 hour domain. This cookie is used by vimeo to collect tracking information. It sets a unique ID to embed videos to the website. Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads. The cookie also tracks the behavior of the user across the web on sites that have Facebook pixel or Facebook social plugin. IDE 1 year 24 days Used by Google DoubleClick and stores information about how the user uses the website and any other advertisement before visiting the website.
This is used to present users with ads that are relevant to them according to the user profile. This is a geolocation cookie to understand where the users sharing the information are located.
NID 6 months This cookie is used to a profile based on user’s interest and display personalized ads to the users. The cookie is used to serve relevant ads to the visitor as well as limit the time the visitor sees an and also measure the effectiveness of the campaign. The main purpose of this cookie is advertising. This cookie is used to identify an user by an alphanumeric ID.
It register the user data like IP, location, visited website, ads clicked etc with this it optimize the ads display based on user behaviour. This cookie is a session cookie version of the ‘rud’ cookie. It contain the user ID information. It is used to deliver targeted advertising across the networks. This information is used to measure the efficiency of advertisement on websites. The purpose of the cookie is to determine if the user’s browser supports cookies.
UserMatchHistory 1 month Linkedin – Used to track visitors on multiple websites, in order to present relevant advertisement based on the visitor’s preferences. The cookies stores information that helps in distinguishing between devices and browsers.
This information us used to select advertisements served by the platform and assess the performance of the advertisement and attribute payment for those advertisements. Used to track the information of the embedded YouTube videos on a website. AddThis log the anonymous use to generate usage trends to improve the relevance of their services and advertising. Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process — were you able to achieve what you had planned? If you are going to fail on estimation versus delivery which I can safely say you will then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message?
How long will it take for pressure to be pushed onto the team? For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This slippery slope further erodes management trust. What if the team is able to deliver value earlier than then when the Sprint will end? Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates.
If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint. If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little.
If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now? The day you start Sprint 0 is the day all the team should be onboard.
Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops. The obvious one is that teams never get started delivering business value.
They stay in this mode of never being ready and there is no drive or motivation to move out of it. This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner. The Scrum Guide defines a Sprint as:. Sprints have consistent durations throughout a development effort.
A new Sprint starts immediately after the conclusion of the previous Sprint. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity the initial backlog creation being a great example. This seems a little odd and misleading to me. You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.
So what would I call it? Make the implicit explicit. Surely the purpose of your first sprint should be to deliver something, however small. Most of that first sprint might be spent removing the initial impediments to delivery and hopefully learning about each others needs on your cross functional team, but at least you start with the same purpose as every other sprint, to deliver some value to the customer, rather than guessing what you will need to enable that.
Modern software development in general, and scrum in particular, is far too focussed on D, D, D and little to no R. We need more research, prototyping, analysis, etc, up front — people who deny that are simply impulsive and not well rounded. We really need to move to prototyping — not potentially shipping things.
Once the requirements have been narrowed down then you can start worry about making the features that survive the prototyping process eg are wanted into production level code. Excellent post! I think it makes the most sense in enterprise environments. Large, complex problems need additional up-front analysis and definition. Diving in too soon results in lots of refactoring or worse, throw-away code.
The software we deliver needs to have staying power. It needs to survive until the final release. Sprint 0 is like any sprint — the team works together to reach the goals of the sprint. If a servant leadership culture is in place then no one really runs the sprint, in organisations transitioning to self empowered teams you do commonly find that the Scrum Master runs the sprint.
You are commenting using your WordPress. You are commenting using your Twitter account. You are commenting using your Facebook account. Notify me of new comments via email. Notify me of new posts via email.
What is Zero Sprint in Agile? Why Do you Use Scrum Sprint 0
So while some teams like to use the end-date of the sprint e. Some organisations adopt the practice of having a Sprint 0 before the project actually kicks off for real. During this time the Scrum team might be assembled and technical issues like hardware, software and colocation issues sorted out. It might also be used to populate the product backlog with a few high-level items in preparation for the first sprint planning meeting.
There are also teams that have a Sprint -1 and a Sprint 0 which together form a discovery process. The sprint -1 would have a small core team that represent the user, business value and what is possible. Using this process you can actually help organisations become more Agile — rather than letting them run a Waterfall pre-project which then goes in to an Agile delivery. Instead it should be about setting vision, creating an initial backlog to meet that vision and getting initial estimates against it.
Teams new to Scrum or transitioning from Waterfall methods often struggle with the balance of what we workout now and what to work out iteratively. A good Agile discovery process before attempting to deliver software is crucial. There are a number of different approaches to sprint zero advocated by Scrum practitioners.
Mike Cohn recommends dispensing with sprint zero and instead having a project-before-the-project which adheres to Scrum values to e. Others recommend having a very short sprint zero during which just a few preparatory goals like putting together a backlog are accomplished. Others still favour a longer than normal sprint called sprint zero at the end of which the team should produce a working increment of the product, as in any other sprint.
Whatever solution you opt for the main thing to keep in mind is that the goal of a sprint is to deliver value. You must also have definitions of Ready and Done and enough stories that meet the definition of Ready for your first sprint. Click here to cancel reply.
This I normally do by just scheduling appropriate meetings and leaving the team members to use the remaining slack time however they feel is best. We do similar things in the name of Sprint 0, i. Scrum in practice: sprint zero. What is sprint zero? Getting the most out of sprint zero There are a number of different approaches to sprint zero advocated by Scrum practitioners. Leave a reply Click here to cancel reply. Andrew Rusling says:. October 30, at pm.
Jim Bowes says:. November 18, at am. Vijay says:. December 3, at pm. November 11, at am. December 26, at pm. Sign up for the Manifesto newsletter and exclusive event invites. Sign Up.