The first Sprint for a team is unlike any other Sprint. And how you plan your first Sprint can help set you up for success… or at least learning (hopefully).
Every team has a Sprint 0, but not every team will have a Sprint 500. Maybe it’s just too chaotic during the formation of a team to take on even more work to optimize Sprint 0. I, however, would suggest treating Sprint 0 as the unique opportunity it is.
Maybe there’s a shortage of skilled Agilest to plan Sprint 0 specifically. I would suggest doing the extra work when planning to maximize the unique value of starting from nothing.
Maybe there is no reason to get worked up about Sprint 0. Maybe Sprints will organically unfold, and it will all work out the same. Maybe, but maybe not.
Definitions:
Sprint Duration: Refers to the fixed period during which a specific set of projects must be completed and made ready for review. Sprint durations are a fundamental aspect of the Scrum framework, and they play a crucial role in maintaining the rhythm and structure of the Agile process.
Velocity: A metric used to gauge the amount of work a team can complete in a single iteration or Sprint. It’s an essential tool for planning and forecasting in Agile methodologies, particularly in Scrum.
Definition of Done: A clear and concise list of criteria a product increment must meet to be considered complete. It is a vital concept in Agile practices, ensuring everyone on the team understands exactly what is required for work to be completed on a user story, feature, or any other product increment.
Definition of Ready: In the context of Agile methodologies, the “Definition of Ready” is less commonly discussed than the Definition of Done, but it is equally important for ensuring a smooth and efficient workflow. While the Definition of Done specifies the criteria determining when a task or project segment is complete, the Definition of Ready outlines the prerequisites or conditions that must be met before a task or project segment is initiated (brought into a Sprint).
DevOps: An approach that emphasizes collaboration, communication, and integration between software development (Dev) and IT operations (Ops) teams. It’s designed to foster a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
Going from Suck to Awesome
Suck – Not acknowledging that besides project work, there is work required to kick off a new team.
Sucks a little less – Starting your first Sprint with a good idea of the team members, project, and overall process that will be used.
Awesome – Working with the team to create the team structure, agreements, and many of the standards used throughout the project. Defining the format and cadence of each ceremony and removing enough dependencies so the team at large can begin work.
Plan Your First Sprint (Sprint 0) for Success
Experienced vs. Novice Teams
The main difference in spinning up a team with members who have previously used Scrum or some other Agile framework (i.e., experienced teams) is that the effort will be focused mostly on decision-making and execution. Teams with a larger percentage of members new to Scrum, on the other hand, will require a lot more education, resulting in an insignificant number of features being completed at the end of the Sprint.
Allow me to break down some of the basic and advanced decisions many teams take on. With new teams, it may take 6 to 18 months to get through all the decisions an experienced team will make in Sprint 0. It isn’t that it takes that long to make all of the decisions, but rather, the team will be working on features and slowly adapting and learning.
No team is ever really done adapting, but there are foundational concepts Agile teams should have in place to get the full benefits of Agile.
I know what you’re thinking. We are already doing Agile; we use an Agile tool; we meet every day, and so on. It is possible that you and your team are comfortable with Agile, but my experience has been that many teams aren’t really doing Agile.
They are like the person who says they go to the gym every day to work out. But when one examines how that person spends their time in the gym, they observe that there’s more chatting, walking around, doing a little of this and a little of that with no real understanding or direction than putting in the work for real results. There are clues, of course. For example, the person has been going to the gym for years but isn’t in shape.
It’s the same with Agile teams. One of my favorite questions is to inquire about the team’s velocity and what improvements they have implemented from the outcome to retrospectives. The answer to a simple question like this is very telling.
Some possible answers include:
We tried retrospectives, but they weren’t very useful, and everyone knows you can only get done what you can get done, so why waste time estimating anyway?
We have a velocity of about 30 points, but we roll tickets all the time, so I am not confident in the number. We do retrospectives occasionally, but we haven’t been able to figure out a way not to roll tickets.
Our velocity is 33 points. The last improvement implemented recently was including a Definition of Done for each story.
Answer #1 is vastly different than Answer #3. Answer #3 is firm. It demonstrates that many practices are in place, including estimation, retrospectives, and continuous improvement loops.
Answer #2 is a middle ground. It shows that the team is working toward foundational competence but hasn’t gotten there yet. Answer #2 indicates the team is aware and actively working on improving their abilities.
I mostly work with teams that answer #1 or #2 (or somewhere between). Occasionally, I come across a team that gives an answer like #3, but it’s rare.
Basic Decisions
Before the Sprint even begins, some basic decisions must be made, including:
Sprint Duration
o How long will the Sprint last? My recommendation is either one, two, or three weeks. See How to Best Handle Injected Work on when it is best to choose a one-week Sprint. With no understanding of any unique business circumstances, I would start with a two-week Sprint if there are no strong opinions one way or another.
Sprint Cadence
o What day of the week will the Sprint start, and what day will the Sprint end?
o What day of the week and what time will each ceremony be held (Daily Standup, Retrospective, Planning, and Demonstration)?
Roles
o What roles will the team support, and who will fill them? Specifically, who is the Product Owner, Scrum Master, and the team? See Small Teams or Large Teams for more thoughts on this.
Agile Project Management Tool
o Pick a tool to manage stories. If other teams at your company already have a tool, seriously consider using what they are using, even if the team has the freedom to select a different tool. Once cross-team work begins, having all teams on the same tool really helps.
Current Commitments
o Although it is unlikely, confirm there aren’t any features currently committed to that are on a specific timeline. Since the team is just forming, it is poor management to have pre-existing deadlines or legal contracts in place, but it’s better to know about commitments than not know.
More Definitions
LeSS: Large-Scale Scrum is an Agile development framework designed specifically for large-scale projects and organizations. It extends the principles and practices of Scrum in a scaled context, aiming to apply the simplicity of Scrum in a larger setting while keeping its original philosophy and ideals intact. Key aspects of LeSS include:
o Simplicity and Scalability
o Single Product Backlog
o Feature Teams
o Less Roles and Artifacts
o Empirical Process Control
o Coordinating and Integrating
o and Continuous Improvement
SAFe: One of the most widely used frameworks for scaling Agile, SAFe offers a structured approach for aligning collaboration across multiple Agile teams. SAFe integrates principles from Agile, lean, and product-development flow, focusing on system thinking, portfolio management, and leadership.
Scrum@Scale: Developed by Jeff Sutherland, one of the co-creators of Scrum, naturally extends the core Scrum framework to deliver efficiently on a larger scale. It is a framework within which networks of Scrum teams can address complex adaptive problems while creatively delivering products of the highest possible value.
Agreements: Also known as working agreements or team norms, these are collectively defined guidelines established by team members to enhance their collaboration and efficiency. These agreements are a crucial aspect of forming a high-performing Agile team. They help set clear expectations to promote a positive, productive working environment. Key aspects of team agreements in Agile include making decisions as described in the section below.
Decisions for Experienced Teams
Relationship to other teams: Will the team be part of a larger group and/or process? For example, is the company using a scaling framework such as LeSS or SAFe? Even if an Agile scaling framework isn’t in use, examining the relationship with other teams is important.
Stakeholders: Who are the stakeholders? In many companies, especially startups, it is hard to determine where to go to get input on requirements. Seek out initial stakeholders and get them involved in the process.
Quality Control: Determine what quality control will be put in place during upcoming Sprints. Specify what Sprint the team wants to take on adding quality control. Typically, it is a little risky to plan several Sprints forward, but in the case of quality, I would recommend setting some rough timeframes. Teams get busy fast, and when they do quality control from automated tests, DevOps can suffer or be completely ignored.
Definition of Done. Create at least the first version of Definition of Done. If possible, document the definition, review it as a team during the first retrospective, and wire it into your story-writing tool.
Definition of Start. Create at least the first version of Definition of Start or Ready. If possible, document the definition, review it as a team during the first retrospective, and wire it into your story-writing tool.
Agreements and Contracts: Contracts or agreements are an advanced topic, but if team members have experience creating agreements, then make some basic ones right out of the gate. Maybe initial agreements are within the team vs. across teams.
Sprint Planning: Expert teams should be able to conduct a thorough Sprint planning meeting. In the beginning, there won’t be time to fully define tickets, so choose stories that either have a low chance of being incorrect or will be easy to adapt in the future. Most stories will probably not be feature-based, but having even a few feature stories helps the team focus on what will be required in future Sprints.
Setting Up Communication Channels: Ensure effective communication channels are established. This might include setting up tools for messaging (such as Slack), video conferencing tools (e.g., Google Meet), and an Agile task-tracking tool (like Jira).
Focus on Team Bonding: Since the team might be newly formed, invest time in team-building activities to strengthen interpersonal relationships and trust. This is easy to overlook, but getting the team together can help the team bond, especially if the members haven’t worked with each other before.
Initial Product Backlog Refinement: Work with the Product Owner to review and refine the product backlog. Ensure the backlog items are clearly understood and prioritized.
Risk Assessment and Mitigation: Identify potential risks early and discuss mitigation strategies. This should always be in focus, but in Sprint 0, the risk is less about the features and deadlines and will instead concern the technical development stack and supporting tools.
Ceremony Format: Define ceremony structure. For example, most teams use the format of “what you did, what you are going to do, and what impediments do you have” for the Daily Standup, but I have worked with remote teams that also include if they are out of the office for any reason in the week. Some teams also formally structure what to do if topics come up out of the scope of the Daily Standup. See the Parking Lot Meetings blog.
Repeat Sprint 0
Typically, teams use “Definition of Done” to describe Stories, but the concept can also be used in other places. For example, “Definition of Done” can be defined for each Sprint. In fact, it is considered the best practice to set a goal for each Sprint. If a goal is set, it is only logical to have a common understanding of when it is complete. Definition of Done can be used for the goal of each Sprint. For example, if the Sprint goal is to add couponing to your ecommerce site, then the Definition of Done could be defined as: “The ability on the production site for a customer to receive a percentage off via a coupon code at checkout.”
So, what do you have to complete to get out of Sprint 0, and what will you do differently once you are out of the first Sprint? Or said another way, what capability do you want after Sprint 0 is complete that currently does not exist? Enumerate those abilities.
Some teams will repeat Sprint 0 until the team develops certain skills. This is an interesting idea, but it shouldn’t be repeated with other Sprints after Sprint 0. There is real value in closing and opening new Sprints as you work through them. BUT Sprint 0 is unique.
I am neutral on repeating Sprint 0 until the definition of done for Sprint 0 is satisfied. I am absolutely against repeating future Sprints after Sprint 0.
The company will probably give you more leeway initially, so take advantage of the extra time and try to get as many standards and processes in place as possible.
Realities of Sprint 0
In the beginning, so many logistics need to be setup that it’s hard to get any actual work (new features) done. The larger the company, project, or team, the harder it is to get started because of company policy, HR, security, etc.
Infrastructure needs to be set up. It is hard to build any features where there is nothing to build them on top of. Think of what infrastructure is required to unblock the team and use that to set priorities. Given today’s complex and expansive infrastructure needs, most likely, it will take several Sprints to get even the basic systems in place. More advanced tools and systems can wait a couple of Sprints before being set up or optimized.
There may be missing team members when a team starts. Some members may be wrapping up other commitments, or some team members may have yet to be hired. I just had the experience of spinning up a team, and half of the team was missing.
In some ways, it was easier to start with fewer people because everyone was new to Agile, and it allowed me to work with a smaller group of people to start with. Try to identify the missing roles and what approximate timelines you can expect to have the missing team members join the team.
In some cases, critical roles, such as Product Owner or Scrum Master, will be absent. What should be determined is whether the missing roles will be part of the team in the short term or the long term.
If the roles will be missing long term, see the Small Teams blog. If members will be onboarded to the team in a couple of weeks, just work with the team to create an initial version of each decision, but know that these roles will be able to help the team refine already-made decisions.
Incomplete requirements are almost always given for new teams. Be very careful not to go too deep into any feature because as the requirements become clearer, you could end up needing to redo a lot of work.
For example, building a shopping cart for an ecommerce store will require the ability to check out, but getting into deeper functionality, such as wishlists and memberships, should be deferred until requirements are available.
Conclusion
In conclusion, the initial Sprint, often referred to as Sprint 0, is a pivotal phase in Agile project management that warrants special attention and strategic planning.
This Sprint stands apart from the rest as it lays the critical foundation for an Agile team’s journey. It is about establishing the core elements to ensure future Agile implementation success. This includes making important decisions about Sprint Duration, Sprint Cadence, team roles, and the selection of appropriate tools.
It also involves establishing the team’s infrastructure, clarifying key Agile concepts (such as the Definition of Done and Definition of Ready), and aligning on team agreements.
Sprint 0 is crucial for both experienced and novice teams, as it represents a period of adaptation, learning, and vital setup within the Agile framework. While it might not involve the excitement of feature development, its importance cannot be overstated in setting the groundwork for future endeavors. The decisions made and the foundations laid during this initial phase have a significant impact on the team’s future velocity, work quality, and overall Agile maturity.
Giving Sprint 0 the attention it needs, actively involving the team in its setup, and making informed decisions can create a conducive environment for an effective and efficient Agile process.
Ultimately, the approach taken in Sprint 0 can be an early indicator of a team’s potential for performance and success in the Agile environment.
Comments