So it’s time to begin a new project. Your scrum sprint is in sight, but wait… are you truly ready? We all naturally start counting from one, often with little regard for the number which comes before. Perhaps we should pay some attention to sprint zero so we can start off on the right foot, truly prepared to take on the upcoming developing task. The necessity and validity of a sprint zero, or if you prefer to call it pre-planning or project setup, cannot be overstated as the benefits to your software development are clear; it will assist in readying your team to build the first product increment. That said, let’s have a look at what key factors can ensure you have an efficient sprint zero.
Let’s begin with the project kickoff; bring the team together for their first meeting. This is the ideal time to ask questions and ensure product understanding for all team members. Get your team to discuss the product vision, goals, priorities, milestones, features to build and more. How about the technical points? Absolutely, the team should confer possible architecture options and decide which is most suitable for the project ahead. Moreover, if the team needs additional time to deliberate the ideal solutions, planning some research and POC during the development is recommended.
Also don’t leave out working style, methods, processes, etc. How will the team work in regards to engineering best practices, and tooling for the project / development / design and so on? Organizing ceremonies will be necessary for jointly reviewing work and continuously improving the product and way of working; therefore, it’s good to include this in the discussion so everyone is fully informed from the start. The importance of all these points cannot be overstated to guarantee a successful sprint. Finally, this is also a good chance to draw up a RAID analysis. This kickoff is the first time for the team to gather and the right time to get everyone on the same page.
It’s great if you’ve done your project kick-off as your starter so you can use the outcome for your grooming of Sprint Zero. Though if not done, fear not, it’s never too late and now would be a good time to do it!
Grooming of Sprint Zero
With the theme of being on the same page, together the team can turn to grooming. In case your mind wanders, we are referring to refinement and the readiness of the team for sprint zero planning. Sprint zero, as any other sprint, requires work readiness, proper planning and a commitment to the delivery of a sprint goal. The team needs to have goals and the same definition of “done” for sprint zero tasks. One person’s definition of “done” can differ from another’s so again mutual understanding of things like this are vital.
Grooming the sprint zero means agreeing on scope and readiness for the deliverables within the sprint zero; the goal is to be ready to build the initial product increment for sprint one. No two sprint zeros are the same, and the scope of work included therein encompasses a variety of things that require attention like the product backlog and architecture, platforms & project tools setup, team’s way of working, learning/training, and no less important, team building. That’s a lengthy list, but stick with me here as we go through it…
Product backlog management
Regarding the product backlog management, this entails narrowing down the requirements to manageable epics and user stories that can be prioritized. What features do the end-users want? Users may have small and big wishlists; time to start that product roadmap and separate them according to delivery milestones required for incremental & iterative completion. You could do a simple exercise such as the Story mapping to help the first conversation.
With that you can begin to prioritize, start high-level estimation, and ready the backlog while also considering the technical feasibility of these features, and the possible initial UI/UX design. This will make the team ready, knowing what to build for the coming sprints. Prioritization is followed by focusing on getting user stories ready for the next increments to build during sprint one and two. To be clear, the goal is not to clarify the entire product, but rather have a vision and understand & highlight the value the team is building.
Initiate the Architecture Runway
Now moving into the architecture runway, which includes the necessities to implement technical features without unnecessary redesign and delay in the near future. The sprint zero must include a discussion about the goals of the architecture and the vision for the solution to be built therein. Your architecture runway must support a continued supply of value. That value comes in the form of developing business initiatives, and implementing new features/capabilities.
The team needs to discuss the technical feasibility of the product itself while also, considering the risks. You recall the RAID you ran earlier in the project kickoff, right? Well now it’s time to look more closely at that analysis. Can you solve any technical, architecture, infrastructure, or compliance issues, risks or dependencies in advance to reduce potential uncertainties you foresee on the horizon? If so, have the team tackle in sprint zero those which are needed immediately; plus, do any technical research & make any technical decisions to ensure moving forward smoothly.
A final point here begs attention, that is the ability to extend the architecture. In order to do so, planning is essential to implement what we call “enablers” to be added in the product backlog. Those enablers can address inadequacies with the current solution or improve foundational capabilities in preparation to support future features/functionalities. This can be done according to what the team understands now and be adapted along the way.
Platforms & Project Tools Setup
Now for Project Tools & Platforms Setup. First, setup technical platforms for building your product which includes your code versioning platforms, your local development environment, your infrastructure and deployment platforms depending on whether or not your application will be in a mobile app store, in the cloud, or on-premise, and any other platforms and tools agreed upon in your engineering way of working discussed below.
Additionally, determining tooling and platforms for project management tools like Jira, Confluence; communication tools like Slack; UX/UI design tools like Figma etc. must be set.
You may be thinking, “well don’t all the team members already have the necessary platforms and access to them?” Perhaps yes, but don’t take this for granted as it’s not always the case. So for that reason, setting and access is really a crucial point here that the sprint zero can address up front to avoid troubles down the road.
Way of working
For the team’s way of working, remember that this is the first time for the development team to come together and may be the first time for some members to work together on the same team/project. Therefore, it’s imperative to ensure everyone discusses, agrees to and understands the working practices that will guide and drive the team forward.
For the engineering way of working, aspects like clean codes practices (ex: Coding standards, projet structure and boilerplate, single responsibility, DRY, design pattern…), automation testing (ex: unit, integration or e2e testing), code versioning, integration and branching strategies (ex:Gitflow), environments and deployment practices (i.e DevOps), documentation practices (ex: Swagger for API, storybook,…), and security and data privacy practices (ex: 12-factor App, OWASP, GDPR compliance…) must be discussed and need to be mutually agreed upon and receive full commitment from the team for best working practices.
For the engineering agreed upon, can any of it be automated? For example, code standards using linter, unit testing code coverage report, IDE plugins, pre-commit scripts, and so on. The team should start upon the DevOps setting, including environment, continuous integration, delivery or deployment (CI/CD pipeline). Why not get the necessary components setup now? At least the first iteration of it to build and deploy. Then consider more advanced practices in your pipeline such as automatic git tagging and versioning, artifact deployment (ex: Nexus, Artifactory), containerization (ex: Docker), Infrastructure as-a-code deployment (ex: Terraform), code quality and security scanning (ex: Sonarcube), third parties library licensing and security scanning.
For working in Agile, agree on Agile ceremonies organization (when, who). For example, if you are applying Scrum, organize your grooming sessions, sprint planning, daily stand-up, sprint review, and sprint retrospective. Discuss your “Definition of Done” but also “Definition of Ready”. If you have a design or concept validation running in parallel with development, agree how the design phase and flow will be organized with the product stakeholders, users and development team. Decide what a first timeline is and how to prioritize design work to be ready for development.
Learning and Training
Regarding learning and training, a key element of any efficient sprint zero, what the team doesn’t know and is needed to build the product must be addressed.
A vital point to the team is working in agile. Does the team understand why and what is Agile? Do they have an agile mindset, sharing the values and principles therein? Are they familiar with the scrum framework of three roles, four ceremonies and three artifacts? And the goals for each of them? If yes, fantastic; you can move forward smoothly. Though if not, now is the time to induct them into that knowledge set to create a unified team approach.
Another vital point here is the technical aspects. What technology is needed to learn short-term to succeed in the coming sprints? Does everyone have the necessary technical skills and infrastructure experience agreed in our engineering way of working and Architecture runway ? Everyone needs to have the same understanding, and as a team possess the knowledge on these points to work together seamlessly and achieve the sprint goals. The same question applies to other “developers” roles in the team. For example, does the QA engineer and UI/UX Designer need to upskill in their area of expertise?
Last, but no less important, does the team need some training on the existing product, the domain knowledge or the product market to better understand the product to build and the feature business values? Training and educating on these points will create more team ownership and make your future sprints more efficient and productive.
This one is blatantly obvious yet sadly, can often be overlooked. People are all different in their own unique ways; that’s what makes life so interesting perhaps. Yet, when bringing a group of people together to work on a product, it’s only natural to find that some personalities may differ. It’s important to get the team members interacting positively early so as to create the cohesive unit you’ll need for development moving forward.
It’s good to then prepare some team building exercises and activities that everyone can take part in to build some mutual comradery and team spirit. Especially for new teams as you’ll have members focused on the development and members focused on the product, we need everyone to understand that they’re operating on one team working towards a united goal. All of this leads to accelerating the team cycle of forming, storming, norming and performing!
What Sprint Zero Is & Isn’t
Sprint zero is not about going back to waterfall to define everything before we are able to begin working incrementally and iteratively. Sprint zero is achieving the goal of having enough for your first sprint to be able to deliver the product increment number 1. Everything within the sprint zero is designed to get the team ready to deliver product value to all invested parties, and build the foundation for a collaborative and productive team. Setting the necessary guidelines, groundwork and whatnot will help your team in the coming sprints ahead.
Among all the items listed above, you will have to scope… remember the grooming of Sprint Zero… your priorities and what is really needed, and plan for other items in other sprints, but timebox it and don’t wait too long before starting to build your product’s first increment.
To sum up our points, remember that learning is an activity that begins with sprint zero, but continues throughout the course of the project. Your architecture runway will have tech enablers in order to seamlessly adapt in later stages. Also, requirements can and likely will change as the client’s needs may change during the course of the project so re-prioritizing is key and having your tooling, work practices and a strong collaborative team in place will ensure it runs smoothly. Lastly don’t panic, there will always be technical unknowns and continued feasibility questions. Fear not, they are not a plague to run from because with your efficient sprint zero, you have a fully equipped and prepared team to handle the plethora of challenges that may assail them. So please do, give a proper nod to your sprint zero!
Tag CloudAgile - Agile Delivery - AI - amazonecommerce - Animal Framework - Attracting talent - Autonomous weapons - B2B - blockchain - businessbuilding - Business building - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Company building - Computer Vision - Corporate startup - cryptocurrencies - de-risking business building - Deepfakes - Deep Learning - DeepMind - derisking business building - Design Research - Developer Path - DevOps - Digital Ownership - Digital Product Strategy - ecommerce - entrepreneurs - Figma - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - Incubator - innovation - Iterative and Incremental Development - legacy system - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - online recruitment - playbooks - Podcast - Product Design - Product Development - Product Development Strategy - Product strategy - product versions - project management - Prototyping early-stage ideas - Quantum Computing - Recruitments - Remote Work - Research - research problem - Robotics - Sales machine - scalable software - Scrum - Self-Driving Cars - Serial entrepreneurs - Slash - software - software design - Software Development - Software Development Company - Software Engineering - Spotify Model - Staff Augmentation - teamwork - Tech Talks - tech teams - tech vendor - testing playbook - The Phoenix Project - Unit testing - user interview - user retention design - VB Map podcast - Venture Building - Venture building strategies - Venture Capital - venturecapital - virtual retreat - Web3