Up until recently, the focus of the agile community has been (rightfully so) on development and delivery activities. After all, the Agile Manifesto was written by 17 people who were trying to address issues that software development teams face.
However, several of those problems arise because the teams don’t have a clear idea of what the right thing is to work on. This is where product ownership and the idea of discovery activities running in parallel to, and perhaps just a little bit ahead of, development ( or delivery) activities come in to play.
Discovery increases your understanding of the need and solution to set up delivery. Delivery is primarily about building, testing, and deploying output, but those activities help your team build further understanding of the need and solution, which in turn influences your discovery. Sure, discovery still happens in delivery, but the majority of work done there is building stuff to help increase understanding.
This issue of Inside Product Management shares a couple resources describing the dual track of discovery and delivery, as well as some of the activities that occur during discovery.
How discovery fits in with development (hint, it’s not duel track)
This article by Jeff Patton explains where the term “dual-track development” comes from, and what it means. The brief version of the summary is that:
- Discovery work focuses on fast learning and validation
- Discovery occurs alongside development work, but is a different kind of work and a different kind of thinking.
- Discovery is a necessary part of product development.
Continuous product discovery is the next evolution in how to build products that customers care about. This case study, presented by Teresa Torres at Front Salt Lake City 2017, will highlight how one organization is adopting continuous product discovery practices across the enterprise. It explores the transformation by the leadership team, by product teams, and by each of the individuals that make up those teams.
Feature (Epic) Refinement is Discovery
You can get a lot of value out of having big items on your backlog (ie features) because you can get a broad view of the overall output you might need to deliver without having to dive into detail on any one particular item too soon.
At some point, though you do need to dive into detail on something in order to start delivery. Feature refinement provides a way to do that in a way that allows you consider options and focus on the essential aspects of the feature and discard the aspects that aren’t completely necessary.
Backlog Refinement is Discovery
Discovery boards are ways for teams to visualize their backlog refinement process. The best discovery boards consist of a whiteboard or wall divided into columns that reflect the various steps a team takes to get product backlog items ready to be delivered (developed and tested) in an iteration. The backlog items are represented by sticky notes or cards that move across the board as the team builds a better understanding of the specifics of each story.
Describing User Stories is Discovery
User stories help us to organize our work and our conversations. The models, acceptance criteria, and examples help us during the conversation to describe those user stories, make sure we’re all on the same page and help us afterward to remember what we talked about so we can go build it. A great deal of discovery also happens during those discussions.