Sprint Zero

You might be wondering, so how do we get started? There is a sort of common misconception that says that agile teams don't do any planning. They do just gather up their friends, gather up their teammates and start building things all sort of willy nilly and crazy like with no direction and no quality. And that's just not true. That's not accurate at all. It's not a fair description of the discipline of Agile. So what we want to talk about is, is how do we get out of the blocks and get started. And I want to introduce you to this idea of the Sprint zero. So Sprint zero is a very common term really used to describe the getting ready to start sprinting with your team. And it can be broken down into three different components. There's the first component that is sort of vision oriented and focused on what the problem in the marketplace that we're trying to solve is and what our proposed solution will be in that space. The next area is where we might identify sort of high level functionality and begin to understand the skill sets needed on the teams to fulfill that vision. And then the third phase is very tactically, how are the teams going to be structured, what are the stories we're going to write and create and even begin to potentially estimate and any training and things like that at the tactical level. So again, sort of three pieces of what we call Sprint zero. Let's look at each of those in a little more depth. When it comes to shaping the vision of the product, we really want to focus in on what problem are we trying to solve? What makes our product different from a competitor's product? How will we make the world a better place? We might, in this phase we might have a kickoff event where some of our executives would share their vision for this product, maybe give a company overview of where we're at and begin to kick us off on this product journey. We really start to also begin to form that product backlog. We start to also talk about release cadences. Maybe there's some milestone dates that are important, a sort of investor demo or maybe a go live date. You know, many products will have go live dates. That all occurs in this first phase. And then in that sort of second piece, we're really starting to come one level down from the vision area. We're identifying the technical underpinnings that will be needed, needed. We're laying out the architecture. We're beginning to really understand what the skills will be needed at the team level and, and even beginning to take some of those epics and, and start to think about what sort of features might be able to deliver to meet the product vision. We we might also map out a training and education plan, an onboarding plan for new team members as they're coming onto the team. And then there's the third piece. It's at this phase where we're starting to break those epics into stories. We're starting to prioritize things or even maybe laying them out over multiple time horizons. We've got the milestones from our executives and our product management group. How do those dates, those milestones fit within a sprint calendar? We're doing our training. We're beginning that phase of forming of our team. We're also beginning to understand what cadence based delivery can look like the sprint. We're beginning to talk through and understand that at the team level. A few other things we might do at this level is begin to maybe even put some estimates on those stories, begin to understand how complex they are, how much we know or don't know about the stories. We might create something called definition of ready and definition of done. Definition of ready is used to help teams understand what are all the things needed in user stories before we can really pull them into a sprint and begin working on them. How is the story going to be ready? It gives the teams an opportunity to talk through that. And then definition of done is, well, how will we know we're done? How will the product owner know how to accept that definition of done? Those are some of the things we'd come up at the team level. Now, just a few more things on the Sprint Zero activity. One is we use the term sprint because remember a sprint is a timebox. It is a set of time where we're going to deliver a certain amount of activities. I recommend you run Sprint zero as a series of sprints if it's going to take more than two weeks. So consider if you have say, say two months where you want to get ready, run that as a series of sprints. Sprint 0.1, 0.2, 0.3. Run them as two weeks sprints. You're building a cadence and getting people used to this idea of sprinting. Run the daily standups, have a back a sprint backlog. What are you going to accomplish in this sprint? Run all of the events that we have within within our Scrum framework. Do a retrospective. Run each of those things as a sprint and you're getting everybody ready. And to understand the heartbeat. Remember I talked about this, the sprint is a heartbeat. Very important. Please, whatever you do, don't make sprint Zero a planning phase from the legacy days of how we used to develop. Don't. Don't do that. Don't fall into that trap. It happens. I see it happen all the time. Well, we do Sprint Zero for six months. Come on, you're not fooling anybody. That's a planning phase, man. Don't do that. And finally, the bumper sticker you might take away on this one for Sprint Zero is you want to get to the least amount of information needed to start sprinting. Boy, that's a different mindset than the traditional let's plan all the workout up front. I'm telling you, get to the least amount of info so you can start working. Why? Because as agilists, we crave that fast feedback. So don't spend a lot of time planning everything out. Look, you can't do it. The technology landscape will shift under your feet anyway, forcing you to make changes. So just get to enough, the least amount possible before you can start sprinting, and that's Sprint Zero.