Starting your first sprint is like starting a fire: it is much harder to start than to keep going. So what is the best way to start your first sprint? When lighting a fire, how you place and stack the wood matters. Do it right and you can enjoy the fire with little effort. Apart from sometimes chucking a log on top. Do it wrong and the fire requires frequent attention to keep burning. It is the same when starting with Scrum. . A poor start lingers and affects upcoming sprints. How you start your first sprint is the foundation for next sprints I worked at 4 different companies where they started using Scrum. I introduced Scrum to eight teams at one of the companies I worked. I noticed when teams started their first sprint, they would often repeat the same mistakes as other teams. I would like to share the 7 most common mistakes that happen when teams start their first sprint with Scrum. 1. Starting with sprint 0. Before starting your first sprint a team member talks about ‘sprint 0’ being necessary. Sprint 0 is a special preparation sprint you need to do before you can actually get started on a real sprint. If you were to reduce Scrum to a single rule it would be this: produce working software at the end of each sprint. Teams may use sprint 0 as an excuse to not deliver working software. Sprint 0 establishes a dangerous precedent: it is fine to have special sprints that are different than others. Do not use sprint 0 as there is nothing to gain by introducing the concept. 2. Neglecting to explain your first couple of sprints will be a bumpy ride. There is no such thing as Sprint 0, but the first couple of sprints your team will struggle more than usual. The first sprint is different because it will always be more vague and messy than sprints that follow. The same principles apply for the first sprint as any other sprint however. In the first sprint, it is not yet clear how much work the team can take on. The sprint backlog will be in poorer shape than usual. Your team may not have worked together before. The team may even be doing Scrum for the first time. Because of this the chance is quite high your first sprint will not go down smoothly. Explain to your team you expect them to fail. 3. Over-committing the first sprint. Deciding how much work to pick up in the first sprint is tough. There are no story point estimates yet and the team does not have a velocity. How do you know how much work the team can take on? An example of a slightly ambitious amount of load somewhere in Africa. In their excitement most teams take on way too much work in their first sprint. During the sprint the team focuses on being busy, instead of making sure the work items wait as little as possible. Items do not get finished quickly. Everybody works in isolation instead of working together. The better approach is to under-commit the first sprint. You will spend more time refining for next sprint than usual. Worst-case you will refine items more than one sprint ahead. By under-committing you force your team to work together to finish items. Because there is not enough work for each person to work the whole sprint in isolation. You will also reduce the risk of carry-over effects of unfinished work in the next sprint. 4. Being unaware of dependencies affecting your team. In an ideal world, your team never depends on others who are not part of the team. As written in the : Scrum guide “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” Guess what? I never worked with any Scrum Team that did not (sometimes) depend on other people who are not part of the team. Some common situations I have encountered over the years: DevOps are not part of the Development Team. Designers work in isolation from the Development Team. User acceptance testing happens after the sprint. Back-end and front-end developers work in separate teams. If you do not manage these dependencies actively, items during your sprint will get stuck. Align your Definition of Done so your team will not get blocked by dependencies outside their realm of influence. By tackling these dependencies before starting your first sprint you will save your team a lot of frustration. 5. Forgetting to prepare for the second sprint. Just finishing what you promise during the first sprint is not good enough. The Development Team needs to work together with the Product Owner to refine enough items for planning the next sprint. Without refined items your next sprint planning will be difficult. If the team uses story points for estimation, then before starting the next sprint it makes sense to establish a reference user story. The development team can use this reference to estimate all work in the first sprint with story points.The refined items you want to add to the second sprint should be story pointed as well. You might think: what is the point of estimating work you have already started working on? After the first sprint you will have a velocity you can use to plan the next sprint. 6. Failing to manage expectations of stakeholders. It is important that you set the right expectations with your stakeholders. The first couple of sprints will be very erratic, because the team figures out their velocity and how to work well together. Give your team the permission to suck by telling everyone your team will perform poorly in the beginning. Sprints may also introduce more structure than there was before. Stakeholders need to be aware they can no longer change everything as easily as before. Want to add something new to the sprint? If it does not endanger the sprint goal, what should we leave out to add your new thing? Maybe the team will even say that they will not be able to pick up your work. Failing to manage expectations will cause frustrations with your stakeholders and may even cause them to undermine your agile transformation efforts. 7. Demonstrating unfinished functionality during sprint review. Unfortunately the sprint review is often quite political in nature. When the team fails the sprint, nobody wants be the one to tell: . Even if the Scrum guide calls it a nowadays and not a anymore. ”We did not finish the sprint as promised” forecast commitment It is much easier to just show work in progress at the sprint review. Somebody in the team says: . Fine, so you show unfinished work and everybody is happy right? ”We did so many cool things, even though it is not finished we can still show it” Everybody expecting the first sprint to be big success leads to failure. Creating an environment where you team has the permission to suck is essential. The purpose of the sprint review is to make transparent what value has been delivered. This is why a clear is necessary to make transparent what ‘done’ means. Showing unfinished work means you are being dishonest about the value being delivered. Definition of Done The beautiful Sagrada Familia in Barcelona. Perhaps the most famous example of unfinished work in the world. Showing work that does not meet the Definition of Done is extremely dangerous. It creates the perception your team is performing better than it is. Imagine next sprint you end up in a slightly better, but similar, situation. Now there is a precedent to demo unfinished work. Otherwise it seems your team is performing worse than previous sprint. Showing unfinished work protects the team from the pain of a failed sprint. But the disappointment of not finishing helps fuel the desire to do it right the next sprint. Failure is good because the people feeling the pain are in power to do something about it. done Well begun is half Doing the following in the first sprint sets you up for success: Do not use sprint 0 as it sends the signal it is okay to not deliver working software at the end of a sprint. Deliver working software at the end of each sprint. Make room to learn from mistakes. Make sure everyone is aware the team will initially perform poorly and that there is a new structured process for picking things up. Give your team permission to suck. Over-committing creates carry-over effects in your second sprint. Under-committing, on the other hand, forces your team to work together to move things forward, instead of each team member working in isolation. Keep your first sprint small. Scrum assumes your team to not depend on others who are not a part of the team to do their work. This is almost never true. By managing these dependencies from the first sprint you prevent your team from being blocked by factors outside the team. A well thought-out Definition of Done can save your team a lot of frustration. Align your Definition of Done with outside dependencies. Use the first sprint to establish a reference. You will have a velocity after the first sprint which you can use to plan the second. Assign story point estimates to all work done in the first and second sprints. Do not show unfinished functionality in sprint review. Functionality is only finished when it meets the Definition of Done. At some point reality will catch up. Presenting a failed sprint sucks, but helps encourage the team to do better next time. Showing actual progress is always better than the false illusion of progress.
