Agile Software Development: How Can You Make an Epic Product?
Part 1 of the "Epic Product" series
Here at ORSYP, we are trying a new Agile software development approach to our software on defining our products. As we go through this transition, I thought it would be useful for us to talk about our challenges and epiphanies along the way. This might be useful for others that are considering the move to Agile product management or have started the transition and could use some friendly advice (or empathy).
Having reviewed the state of the art (and state of confusion in some cases), we’ve based our approach on three concepts, adapted to our needs:
- Personas – defines your product’s audience
- Epics – defines your audience’s essential questions and goals
- Stories – defines the workflows that your product will provide to answer those questions and reach those goals
There is a fair amount of industry agreement on stories and personas, but much less on epics. Consequently, we have followed the “adopt and adapt” philosophy and have adapted epics to suit our intention to use Story Maps.
So how do these concepts come together to help us?
- Personas help us to viscerally identify with our users and understand their priorities. They help us avoid gold-plating in the requirements and are a basis for discussing what is important and what is not across departments. They help us put ourselves in the customer’s shoes in a way that was not easy to do before. They also help to guide our RBAC decisions in a realistic way.
- Epics document the reasons why our customers buy our products. They help to separate “product pain” (pain created by the product itself) from the original needs of the customer. By prioritizing epics, we can engage in a discussion that helps us understand the core mission of the product vs. the more peripheral nice-to-have goals of the product. Associating epics with a prioritized list of personas creates an even more vivid picture of the relative importance of each epic, making development decisions easier. Finally, epics help us to define a “theme” for each release, which gives extra focus and unity to the organization.
- Stories force us to think about the user experience instead of the screens and implementation details. They help us to focus our displays to ensure that only the necessary data is displayed. Most importantly, a prioritized list of stories helps us to avoid building code we don’t need. By relating stories to epics in a story map, we get a more intricate picture of the relative importance of each story, which helps us keep our development efforts focused on the highest value for the end users.
These are the benefits that we hope to attain. I have experience in this from a previous life, so I am confident that we will realize these benefits as we move down this path. However, every organization is different and we are just starting out on this journey. I hope you enjoy this series.