{"id":6522,"date":"2022-09-19T16:17:47","date_gmt":"2022-09-19T08:17:47","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&p=6522"},"modified":"2024-02-15T12:43:44","modified_gmt":"2024-02-15T04:43:44","slug":"9-key-factors-for-an-efficient-sprint-zero","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/9-key-factors-for-an-efficient-sprint-zero","title":{"rendered":"9 key factors for an efficient sprint zero"},"content":{"rendered":"

So it\u2019s time to begin a new project. Your scrum sprint is in sight, but wait\u2026 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\u2019s have a look at what key factors can ensure you have an efficient sprint zero.<\/span><\/p>\n

Project kickoff<\/h2>\n

Let\u2019s 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.<\/span><\/p>\n

Also don\u2019t 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\u2019s good to include this in the discussion so everyone is fully informed from the start.<\/span><\/p>\n

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.\u00a0<\/span><\/p>\n

It\u2019s great if you\u2019ve 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\u2019s never too late and now would be a good time to do it!\u00a0\u00a0<\/span><\/p>\n

Grooming of sprint zero<\/h2>\n

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 \u201cdone\u201d for sprint zero tasks. One person\u2019s definition of \u201cdone\u201d can differ from another\u2019s so again mutual understanding of things like this are vital.<\/span><\/p>\n

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 & \u200b\u200bproject tools setup, team\u2019s way of working, learning\/training, and no less important, team building. That\u2019s a lengthy list, but stick with me here as we go through it\u2026<\/span><\/p>\n

Product backlog management<\/h2>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

Initiate the architecture runway<\/h2>\n

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.\u00a0<\/span><\/p>\n

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\u2019s 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.<\/span><\/p>\n

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 \u201cenablers\u201d 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.<\/span><\/p>\n

Platforms & \u200b\u200bproject tools setup<\/h2>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

You may be thinking, \u201cwell don\u2019t all the team members already have the necessary platforms and access to them?\u201d Perhaps yes, but don\u2019t take this for granted as it\u2019s 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.<\/span><\/p>\n

Way of working<\/h2>\n

For the team\u2019s 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\u2019s imperative to ensure everyone discusses, agrees to and understands the working practices that will guide and drive the team forward.\u00a0<\/span><\/p>\n

For the engineering way of working, aspects like clean codes practices (ex: Coding standards, project structure and boilerplate, single responsibility, DRY, design pattern\u2026), 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\u2026) must be discussed and need to be mutually agreed upon and receive full commitment from the team for best working practices.<\/span><\/p>\n

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.<\/span><\/p>\n

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 \u201cDefinition of Done\u201d but also \u201cDefinition of Ready\u201d. 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.<\/span><\/p>\n

Learning and training<\/h2>\n

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.\u00a0<\/span><\/p>\n

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.<\/span><\/p>\n

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 \u201cdevelopers\u201d roles in the team. For example, does the QA engineer and UI\/UX Designer need to upskill in their area of expertise?<\/span><\/p>\n

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\u00a0 make your future sprints more efficient and productive.<\/span><\/p>\n

Team building<\/h2>\n

This one is blatantly obvious yet sadly, can often be overlooked. People are all different in their own unique ways; that\u2019s what makes life so interesting perhaps. Yet, when bringing a group of people together to work on a product, it\u2019s only natural to find that some personalities may differ. It\u2019s important to get the team members interacting positively early so as to create the cohesive unit you\u2019ll need for development moving forward.<\/span><\/p>\n

It\u2019s 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\u2019ll have members focused on the development and members focused on the product, we need everyone to understand that they\u2019re operating on one team working towards a united goal. All of this leads to accelerating the team cycle of forming, storming, norming and performing!<\/span><\/p>\n

What sprint zero is and isn\u2019t<\/h2>\n

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.<\/span><\/p>\n

Among all the items listed above, you will have to scope\u2026 <\/span>remember the grooming of\u00a0 Sprint Zero\u2026<\/span><\/i> 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\u2019s first increment.<\/span><\/p>\n

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\u2019s 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\u2019t 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!<\/span><\/p>\n","protected":false},"featured_media":11003,"parent":0,"template":"","resource-topic":[54],"resource-type":[43],"class_list":["post-6522","resources","type-resources","status-publish","has-post-thumbnail","hentry","resource-topic-agile-development","resource-type-articles"],"_links":{"self":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources\/6522","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources"}],"about":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/types\/resources"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media\/11003"}],"wp:attachment":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media?parent=6522"}],"wp:term":[{"taxonomy":"resource-topic","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-topic?post=6522"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-type?post=6522"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}