Getting a New Scrum Team Started (Part 1 of 2)
The Scrum Guide provides no reference or guidance on how to get started with Scrum. That's because Scrum is a lightweight, minimal framework to encourage self-organization. I have heard it stated that Scrum is intentionally incomplete. There are no special Sprints in Scrum, such as Sprint Zeros, either, which leaves many new to Scrum wondering how to get started.
Since I've gone through this myself and have helped a lot of new Scrum Teams get started over the past decade, I decided to share what I do and write down the recommended steps I typically take with a new Scrum Team to get started. This is part one of a two part series.
If you only had one day to get started...
Let's say that you've joined a new Scrum Team as the Scrum Master for an important new flagship product, and the stakeholders are eager to see the team get started and make progress. They've heard about Scrum and want to know how long it will take before the first Sprint starts. Leadership will support you with whatever the team needs to be successful. So, how long will it take to start Sprinting? And, what needs to be in place before the first Sprint?
What would be your answer? One day? One week? One month?
My answer would be "we can start Sprinting in one business day or less!". The only caveat is that we need a Product Owner and Development Team to join me, the Scrum Master. You won't be successful with Scrum without the roles filed. But just one day you ask? Yes, one day, this isn't waterfall where we need to plan everything up front. I have spoken with Product Owners and teams who have spent weeks, sometimes over a month, trying to capture everything in the "perfect" Product Backlog, only to find out that they didn't know everything up front. And worse, some of the Product Backlog was never implemented. Don't get stuck in the old, traditional waterfall way of working! I have worked with teams who create enough Product Backlog items to get started in less than a day, and they were still successful while minimizing waste. Remember, you don't need to know "how" the Product Backlog items will be built, that will be determined in Sprint Planning and throughout the Sprint by the Development Team. And you don't need an exhaustive list of Product Backlog items either, you will discover new items as you get feedback from stakeholders, and even better, customers and end users of your new Product. That's the beauty of empiricism, we'll make decisions based on what is known.
You don't need an exhaustive list of Product Backlog items, you will discover new items as you get feedback.
Scrum only requires these pieces be in place before the first Sprint starts:
A Scrum Team consisting of a people fulfilling the roles of Product Owner, Scrum Master and Development Team (optimal size would be 3-9).
Enough "Ready" Product Backlog to fill a Sprint (Sprints are limited to one calendar month).
A definition of "Done".
The Product Vision
I add in one more task to get started, which is not required by Scrum: the Product Vision. I recommend this be the first acton you take above all else. Consider the Product Vision a complimentary practice that you will use to kickstart your initial Product Backlog conversation, and inspire your team in upcoming Sprints. I like to include everyone when coming up with the vision, not just the Product Owner, including the Development Team.
There are many ways to facilitate a Product Vision that have been documented elsewhere, so I won't repeat those. Here are two of several ways you can explore to create the Product vision. Again, this isn't required in Scrum but will make a big difference now and in the longer term, so spend some time doing this.
Product Box, from Innovation Games
The Elevator Pitch Template, from ProdPad
The Product Backlog
As I mentioned above, you don't need an exhaustive list of Product Backlog items to get started, because the Product Backlog will emerge over time as more is learned. But you'll need a few Product Backlog items to fill the upcoming Sprint.
Another important tip is that you don't need to know how Product Backlog items will be implemented at this point, as that will be figured out during Sprint Planning and the Sprint. Stick to the "what", not the "how".
In part two of these series I am going to talk about using Story Mapping to determine a Minimal Viable Product (MVP), Roadmap and release candidates. But for now the best advice can give is to come up with some Product Backlog items that are needed to get started. Some of these items may even be technical in nature, such as architecture or tools (e.g. The need to set up CI/CD and automation), and that's fine. But remember to deliver some functionality to keep your business stakeholders interested and to validate those technical items.
The Definition of Done
Now let's discuss the definition of "Done". In Scrum a "done" product Increment is required every Sprint, and that's important. It doesn't mean that you have to release the Increment, but it has to be in a 'potentially shapable' state. So as a Scrum Master you'll have to figure out a way to facilitate a definition of "Done" for your Development Team. A good first place to look is to see if your development organization already has some standards in place. From the Scrum Guide:
If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product.
If there isn't one at the organizational level, your Development Team needs one! If you've not taken a Professional Scrum Master course, I highly recommend one as we discuss this topic in depth. But if you need to get started right away, here are some articles which should help you:
Improving Your Definition of Done, by Simon Reindl
Why Scrum Requires Completely "Done" Software Every Sprint, by Christiaan Verwijs
Walking Through a Definition of Done, by Ian Mitchell
That's it, the Product Vision and three items required by Scrum are all that is needed before you start your first Sprint. Is that perfect? Nope, it isn't by any means, however in my experience it is best to dive right in, and make transparent what else will be needed in the future.
I suspect my list may be different than yours, and that's okay. There is no perfect way to get started or set of best practices when it comes to building complex products. I encourage you to experiment to see what works for your teams.
In part two of this series I will discuss what else I do to continue the momentum, and share more details on things like team building, story maps, roadmaps, lean canvas, metrics and more.