If you ask around the development world, you’re pretty likely to hear some heated discussions about Sprint Zero. While some people might argue over whether it should be called Sprint Zero – or if teams should even have a Sprint Zero – it has become an integral part of our agile web development process. Just like all of our sprints, Zero is centered around the client. But rather than being focused internally on our work, Sprint Zero gives us the opportunity to have a free-flowing, creative environment that focuses on identifying users and building our goals. While it may be controversial, at 352 it has become an invaluable tool that ensures no potential user is forgotten, and no possible feature is overlooked.
In this week’s 352 Noodles & Doodles, I walk you through how 352 makes Sprint Zero work for us and for our clients.
Photo credit: Mirus Luna, Wikimedia[Leo Rodrigues:] Hi, my name is Leo Rodrigues and I’m a software developer here at 352. Under the realm of Scrum 101, we’re going to talk about Sprint Zero. Sprint Zero can be a little bit of a controversial topic out there in the industry. It has a lot of grey area. If you Google Scrum and Sprint Zero, you’re going to find a vast amount of information including questions like, “Should we even do Sprint Zero?” or, “Should it be called Sprint Zero?” And yes, people out there argue if Zero should be the name of the enumeration of the sprint. We’re not going to get into all of there here. The fact is that we have effectively adopted Sprint Zero at 352 in our typical projects and we’re happy with it. So I’m going to share a little bit about the overview of what happens in Sprint Zero. First of all, the length. We’ve typically found that in about 2 – 3 days, we get to accomplish everything that needs to be accomplished in a Sprint Zero. During that time, we start having conversations, we try to keep a very free-flowing creative, engaging format. And we start identifying users. Users of the site, or the target audience for the client’s project. And, it is very important that at the time, to have a free-flowing format. We have gameplay, exercise. Depending on the project, we pick and choose what kind of exercises we engage in. The important part is that we think of it as a long, 2 – 3 day conversation where the customer and the developers come together to form one team. We just chat and discover thing. So, we discover our users, right? And typically, that can be a confirmation of what the client already knew their user base was, but the free-flowing format oftentimes also allows us to discover a new user base, a new target audience that we didn’t know existed. Then, we keep talking and we go on to identify the goals for the project. Again, the same type of thing happens where clients may come in with a set, defined list of goals and those are fine, but we may even discover new things. Somebody may come up with a new idea that everybody may say, “yeah, we like that – put it at the top of the list!” Or, “Yeah, we like that idea but put it at the bottom of the list because the other goals are more important.” Or, just toss it out, right? Either way, the free-flowing format and brainstorming are key. So we have our users and our goals, then we’re ready to start talking about the product backlog and start populating it with items. The items that will start entering the product backlog are going to make the goals happen for the user base. So we have lots of conversations, populate the backlog, and we may have a million items in the backlog. We just keep entering them – there are no bad ideas, just keep entering them in the backlog within some sort of limit and common sense. We keep it within the realm of the goals and keep the user base in mind when talking about features and items entered in the backlog. Typically we just enter away until we reach a moment where conversation ceases and everyone feels like we got everything down. That’s the time to stop. So we end up with a million things in the backlog and features and items. At that point, because we have a limited timeframe for an engagement – typically a number of weeks to begin with, and those will translate into a few sprints – we cannot deliver a million things in that timeframe. So we have to start prioritizing and define what set of features are – from the backlog – going to accomplish the set of goals we’ve defined to serve the user base that we’ve defined, that is most important. That set of features and backlog items will make up your minimal viable product, and that’s what you’re going to bring out to market at the end of the engagement, at the end of the initial sprint we’ve set out to engage in. And the rest of the items become future backlog items for other iterations. That’s it. If you have any questions, feel free to post as a comment or question and I’ll be happy to answer them and start a conversation about it. I hope this was helpful and thank you for watching.