Feature Discovery and Delivery: To Split or Not to Split?
Being a PM is not a piece of cake. You probably know that by now. You have probably also encountered a long list of features hanging in the air, unsure why half of these features were on that list in the first place.
This is exactly why brief discovery projects are important in figuring out whether it’s worth developing a feature before going into the details of how to develop it at all.
Dual-Track Scrum
If you have ever considered doing discovery before developing a feature, you might have also heard about Dual-Track Scrum. It’s an agile method that separates work with a feature into Discovery and Delivery.
Discovery is about validating an idea, determining whether it makes sense to do at all. Delivery is about determining in detail how to build it and then actually building and releasing it. The primary reason to separate the efforts of discovery and delivery is to make sure you’re not wasting more time than necessary on features that should not be built anyway.
Discovery is typically done by a discovery team, with three distinct roles. The PM determines whether a feature can be valuable to a customer/stakeholder, the designer determines whether it can be made usable, and the developer determines whether it is technically feasible to build and also provide estimates for how long it would take to build.
One way to find the version of a feature that is valuable, is to do a User Story Mapping. Another approach that is often used by designers is the Double Diamond, where extra effort is put into making sure the right problem is being solved.
Delivery is done by the delivery team, and can be split into two phases. In grooming, the feature is fleshed out in more details. The final set of user stories and requirements to be fulfilled and the exact specifications and designs are determined. In development, the feature goes into a sprint and is coded and then released.
Why It Makes Sense to Split Discovery and Delivery, Separated in Time
Usually after the discovery phase, a feature goes back to the roadmap, this time with less uncertainty attached to is. Doing it like this, with two steps is the essence of Dual-Track Scrum. Separating out Discovery ensures that only features that make sense to do, i.e. that are valuable, usable, and feasible, go into Delivery.
In other words, the goal is to achieve maximum outcome with minimum output. Outcome refers to the effect of the solution or the value you’re trying to deliver to the client’s issue, and output refers to the amount of new functionality that is built.
Key here is to deliver value, outcome, building the least possible amount of functionality output. Why release a software with a thousand features to solve an issue, if the same could be achieved with a hundred well-designed features? Less is more here. Dual-Track Scrum gives the teams more focus, reduces their rework and improves the ability to plan, while maintaining agility.
Separating Discovery of a feature from the process of detailing out its requirements and specifications can be very useful. However, it’s crucial to keep a balance and make sure that these two are not too separated. This could lead to information and insights being lost, which risks efforts being wasted.
The Risk of Splitting
If the discovery team and the delivery team consists of different people, or if there are several weeks (or even months) between the phases, then the insights from Discovery risk not being caught. A bad handover can lead to three main problems.
First, late-stage changes in the way of implementing the feature risk not solving the original problem the customers/stakeholders had in mind, if the underlying feedback that triggered looking at the problem in the first place is not handed over into Delivery properly.
Second, there is also the flip-side to the issue above. The development team may believe a certain aspect of the issue is crucial to solve, and put lots of effort into solving it only to find out later that it was actually not that important. This results in wasted time and effort.
Third, to avoid the two problems above, if the handover has not been done properly, the PM and the developers may have to spend time going back and forth in further meetings to clarify things, potentially involving stakeholders in more discussions.
Split While Keeping the Connection
A good way to make sure the connection between discovery and grooming is not lost is to use the same document across the two phases. When the feature Discovery is recorded in a document, it can be directly handed over into Delivery.
If done properly, this means that the relevant notes from Discovery, including why the problem is being solved in the first place, are handed over — which goes a long way towards resolving all three of the above mentioned problems.
A good document can also help avoid the following problem. If the development team is not properly involved in Discovery, there is a risk that it turns out that the way the feature was envisioned during Discovery is not feasible.
If this is found out during a sprint, then that results in a disruptive postponing of doing the feature, which leads to wasted time. With the Discovery recorded in a document that is handed over to Delivery it is more likely that your team will find this problem earlier.
Start with a Template and Let It Evolve
Using a template is a good approach to make sure documents are consistently written in a way that lends itself to a handover between Discovery and Delivery.
At Delibr, we interviewed over 300 PMs about their work with discovery and grooming of new features. And based on what we learned, we made a template that we believe can support the ways of working that seemed to work best:
We wrote the template specifically with this two-step process in mind. During Discovery, the teams work mainly with the topics in the Background section, and draft user stories in Stories (and maybe add a few brief points in Details).
During Delivery, the team works to add more details to Stories, adding relevant details as sub-bullets each story. The Details section typically also grows in this phase. Meeting notes can also be captured in the same document to make it is easy to go back and see what was discussed.
Starting with a template means that sometimes some of the headings will need to be revised, as all features are not the same. Another problem with working with a document like this is that it tends to grow, and over time risks becoming overwhelming. A good way to handle both of these problems is to use an outliner.
An outliner is a type of document writing tool that was originally used by authors and screenplay writers, but that is gaining wider use. Using an outliner makes it easier for the PM to see the hierarchy of a document, rearrange content, and focus by collapsing parts of the document.
This way, the document can contain all the relevant information and details from both Discovery and Delivery, but still not look or feel overwhelming. Delibr is such an outliner, and below screen capture gives a glimpse into what it can be like to work with more structure:
To conclude, splitting Discovery and Delivery can be very useful to save time, resources and hassle for your team if you’re aspiring to be a great PM. However, the magic works only if the splitting is done right, otherwise it might back-fire and complicate the situation. Starting with a template and using an outliner to let it evolve with structure will make it easier to do it right.
Originally published at https://blog.delibr.com on August 30, 2019.
