In the first of two blogs, we discussed the role of product discovery in Professional Scrum and how discovery can help Scrum Teams approach problems, validate understanding, and ultimately deliver more value to customers, users, and stakeholders. We also explored how discovery can apply to significant things and small things and does not just apply to large problems. However, there are many false truths associated with product discovery in Scrum. Here are some myths and the reality:
It's a phase in the process and can not be done in a Sprint.
This is a very worrying idea and encourages the concept of two-phase Scrum or Design Sprints. The reality is that the best Scrum Teams will be doing discovery throughout. Of course, some Sprints will be more discovery than others. However, at the heart of Scrum is the idea that cross-functional teams pursue a Product Goal. They will do whatever makes sense to deliver on that Product Goal and do that as a team.
One exciting pattern for mature teams is the idea that a Scrum Team will be dealing with three horizons at any one time:
- Horizon 1- bugs and issues with the product today
- Horizon 2 - features that are well understood and are the focus for this release or product horizon
- Horizon 3 - crazy ideas for the future and experiments for the future.
If your product has no significant quality issues, then Horizon 2 is where your Sprint Goal focuses, but the other two horizons can not be ignored. This allows teams to get a handle on the future, and those thoughts can also help improve our Horizon 2 work. Of course, discovery can apply to all horizons.
I hear some of you shout, ‘But, what about focus?’ And there is some truth to that. Working in a multi-horizon world is a challenge, but the benefits can be amazing. I trust Scrum Teams to make the right choices about focus. Also, we have two great places to review progress and focus: the Sprint Review and the Retrospective.
It is only for greenfield projects.
How often have you been involved in work that started with the phrase, ‘ok, this is simple, and we know what to do,’ and then you realize that it was not as simple as you first thought? The reality is that discovery happens throughout and that the discovery process should not only be applied to greenfield projects. Of course, there are constraints, and it is essential not to spend so much time discovering that you never deliver something. However, the idea that you deliver “stuff” to aid in discovering value is a critical concept that should be applied throughout. As products mature, more discovery and product delivery can be co-mingled, allowing each increment to deliver more “stuff” that helps us discover value.
It is too expensive and slows us down.
Ok, here is a fact. When you release a new feature or deliver some value and get it wrong, it will be much more expensive and time-consuming than if you do not do it. Doing the wrong stuff might look good on a velocity chart, but it does not ultimately reward the investors, customers, and users. Discovery is all about trying to find a balance between understanding and delivery. Make choices about how much work needs to be done to know enough to warrant more investment. Discovery is more of a mindset that relies on practices and tools than a set of tools that can be used within an approach. The mindset constantly questions the investment, always looking for proof points and evidence. Backlogs are reframed to describe outcomes in pursuit of a goal. Everything becomes measurable and outcome-oriented.
Developers do not want to do it.
When you talk to Scrum Teams about discovery, they often say, “ that is a job for the Product Owner, analyst or tester, not for us.” Not everyone in the team wants to meet with stakeholders and explore the why. And that is why we have a cross-functional team. Discovery is much more than meeting users. It requires many skills and activities, from user interviews to building prototypes and actual features. The team can perform these activities, allowing different teammates with different skills and aspirations to do different discovery work. However, Discovery requires that everyone be interested in the user and stakeholders. The problems and their solutions are not the province of a few but of the whole team. A Scrum Team is responsible for delivering value, and that requires discovery. But not everyone has to do everything.
The Definition of Done (DoD) stops us from doing Discovery.
The Definition of Done is a commitment to the Increment. It describes the attributes of the work to be considered done and part of the increment. It provides everyone involved with a clear description of quality. As a constraint, it forces the Scrum Team to concentrate on finishing things rather than partially finishing things. The Sprint Review focuses on done work.
So, how does the DoD affect Discovery?
Well, it depends. In some cases, it can clearly define what Discovery items must present, such as a measurable hypothesis, a clear set of success criteria, a key persona to focus reviews on, etc. In other cases, the discovery work does not have to conform to the DoD and will be reviewed in a separate meeting or after the Done Increment is reviewed. In these situations, discovery is more like a refinement activity.
It is essential not to be dogmatic but transparent. The DoD provides a clear baseline for completed work. If something is being reviewed that needs to be completed, then that should be clear to everyone reviewing it, and that should be discussed. It is also vital that everyone who reviews a product understands the expectations of the quality of that product. The DoD provides a clear line in the sand for the Increment.
Putting the empirical in Professional Scrum
Professional Scrum is empirical. The idea is that you break things down, deliver them, and learn by that process. However, the economy and focus of that empirical approach should be led by value. Product Discovery is the discipline that provides that mindset. It encourages Scrum Teams to ask questions about value, build hypotheses, and test them. It forces teams to ask, “What is the best, quickest, and cheapest way to prove that assumption?”.
Product Discovery enables Scrum Teams to be smart in delivering value.