So, you have decided to use scrum for your product development, but you’re not quite sure where and how to start or what are the critical items you need to address before starting. As you prepare for the new year, it’s a great time to pause and make sure you begin with clear purpose and expectations in your next endeavor.
And, good news! Scrum is easy to begin with—no special equipment or tools are required. It is a simple empirical framework for ensuring unfettered transparency, frequent inspection, and immediate adaptation. The three roles, three artifacts and five events of scrum that enable scrum’s empiricism are outlined in the Scrum Guide.
The harder part though is knowing how to define your purpose before you get started running sprints. Since scrum is a framework, it does not prescribe how you do this, nor what to consider before getting started. That’s okay. We’ve helped hundreds of scrum teams get started, and here is some guidance on the things you need to know before you get started.
1. Ensure Strategic Stability
The first and foremost step before you start using scrum is to clearly define your product’s vision. The product owner, the customer, key stakeholders and the development team should collaborate on defining a rough sketch of your end product, including:
- Who is your target customer?
- What is the problem being solved?
- What will your product do to solve it?
- How is your idea to solve it different and valuable compared to alternatives?
- How does your solution or idea align with your overall organization’s strategy & purpose?
When defining purpose, remember that less is usually more—keep the vision statement simple and easy to understand. If you need pages and pages to explain your product vision, you probably don’t really know what your ultimate destination is. If you can explain it in 2-3 sentences (like an elevator pitch), you’re probably on to something your entire team can wrap their collective head around.
You don’t need to know everything before you do anything. At the beginning of a project or product lifecycle, that’s when you know the least about your product or project. Accept that, first of all. Starting with a lightweight vision statement and a holistic and digestible product roadmap to visualize how you’ll achieve your product vision is the foundation you need to get started. Your vision is your beacon or destination. How you arrive at your desired destination (strategy) can be accomplished in a variety of ways (tactics), through experimentation.
2. Be Prepared to Experiment…a Lot
Your idea is going to be based on a number of assumptions. Know that you’ll need to continually run experiments to test your assumptions (i.e. hypotheses). Your experiments will be done within releases and sprints. Gathering feedback from stakeholders in sprint reviews and from end-customers each release is the data you’ll use to validate the assumptions made in your sprint and release goals.
With a product roadmap, you have your initial cut at your product backlog. Granted, before you get started, your product backlog is still at a high-level of detail. Don’t worry, it’s enough for your product owner to have a rough idea of the priority of it all. The top priority features should have a place in the product backlog at this stage.
The two main factors your product owner should use in determining priority are value (business value or customer value) and risk. Value probably seems obvious, but in case you’re wondering why high-risk product backlog items should be prioritized to be implemented at the beginning, consider that at the beginning the following are at play:
- You have the simplest system you’ll ever have again in your product’s lifecycle
- You have the longest runway remaining to “take off” successfully
- You have the most amount of resources at your disposal to validate assumptions and mitigate known risks
- If the highest risk items are going to result in any type of failure for whatever reason, at least you’ll be able to fail quick, early and cheap
Remember: Don’t boil the ocean. You only need one sprint’s worth of product backlog items to get started running experiments to validate your assumptions, deliver value to your customer and start gathering valuable feedback. Check out how Nordstrom did this directly with their end-customers.
3. Your Product Owner Is the Key to Success
Too often, products fail because the product owner role is misunderstood or poorly implemented in at least one of the following ways:
- The product owner is not available to the scrum team throughout each day
- The organization has not identified someone to be dedicated to collaborating with customers, stakeholders and the development team
- The product owner is not empowered by the client and development organization(s) to make tough business decisions every day
- Two or more people are trying to fill the product owner role, resulting in confusion about priority and direction
- The person filling the product owner role is disconnected from the customer and users (e.g. comes from IT, new to the industry, not familiar with product ownership techniques, etc)
- The product owner does not provide clarity to stakeholders and/or the development team on why priority decisions are being made
- The product owner tells the development team how to technically implement the solutions identified for meeting customer needs
Establish trust in your product owner by empowering him or her to make tough business decisions about the product. The management and sponsors should have faith in the product owner and accordingly delegate decision making. All stakeholders (which includes managers, supervisors, sponsors, etc) who are engaged with each sprint review will have the opportunity to influence the product’s development multiple times per month. They need not feel the need to maintain day-to-day control with an empowered product owner. The scrum team, customer and organization will soon lose confidence in a product owner if he or she has to approach the collective of stakeholders for every decision. They also won’t be able to respond effectively to the changes in customer needs and market conditions with such delayed and decentralized change control.
It is also best to have the product owner collocated with the scrum team. The product owner should neither be overworked nor burdened with multipe products or diverse responsibilities. Lack of access to the product owner is a key contributing factor to the poor product owner implementations listed above.
Your product owner should have excellent communication and negotiation skills, be available to and engage effectively with the scrum team as well as the broader product team (i.e. scrum team + stakeholders) and must be a visionary and doer. With these qualities and appropriate empowerment, the product owner will be exactly what is needed to drive the scrum team towards success.
If you’re looking to start things off right with your product in the new year, attend one of our classes or contact an adviser for coaching.
