How To Increase ROI with Value Driven Development
A version of this blog post’s content was originally presented at DrupalCon Asia 2016 in Mumbai and DrupalCamp LA 2016.
Tired of not knowing developer communications-fu? If you’re a product owner, product manager, project manager, stakeholder, or simply a client with experience with a web development project, you’ve certainly felt the pain of miscommunication with developers. Perhaps you’ve even wished you could download some developer-fu directly from the matrix.
Quite simply, the lack of effective communication leads to additional costs during development, frustration, and time lost to project extensions. All of which are costly side effects of imperfect communication practices between stakeholders and developers—inflating your investment and decreasing your ROI.
Short of being able to tap into the matrix to communicate mind-to-mind with developers—you need a better toolset for communicating around development projects. To stop the frustration at its source, pick up a few agile discovery techniques that allow better communication, understanding, and focus around developing value-driven solutions.
Enter: Value-Driven Development with Agile Discovery
Value-driven development with Agile discovery allows you to iteratively zero in on solutions that deliver value to the business. For those of you familiar with agile practices, you can think of this as an agile backlog verification process taken up by the product owner prior to sprint planning.
To start, you have to take a rough outline of features and give it life.
The Feature Tree
The Feature Tree is a rough outline of what product owners and stakeholders think will be valuable in an application. With time constraints, most discovery workshops end up producing a rough outline of what needs to be built—similar to coloring in this tree with a crayon.
Feature Tree after a discovery workshop. Rough idea of the amount of work to be done, but no clear resolution on individual tasks.
Since you are trying to scope much of the project in a single discovery workshop, you end up with a low-resolution image of what should be built. This low-resolution sketching of a tree can prove costly later in development if you don’t take time to detail all of the leaves, or stories, that will make up the valuable features of your web project.
Why are discovery workshops important?
Before we go further into the solution, let’s talk a bit about why discovery workshops are important.
To put it bluntly, discovery workshops aren’t perfect—they are just your next best alternative to tapping into the matrix.
Not everyone can dodge bullets. Discovery workshops are your next best alternative.
While the first discovery workshop is imperfect, it is necessary to build a foundation of shared understanding between developers, solutions architects, product owners, and stakeholders. This is the foundation you establish for future conversations. It is important to note while the first discovery workshop is critical, you will get most details wrong.
Execute the first discovery workshop to:
- Build a foundation of shared understanding;
- Draw things—ideas, wireframes, diagrams;
- Narrow the cone of uncertainty around delivering this project;
- Get a rough sizing for the amount of work required (but understand this will likely change over time);
- Tell a story about value delivered to the end user;
- Tell a story about value delivered to the business;
- Find a balance between the cost of developing a solution to deliver value to the end user versus value delivered to the business.
Narrowing the Cone of Uncertainty is about mitigating risk around the project.
Mitigate risk for the development team by:
- Improving scope comprehension
- Providing context for external factors on timeline such as deadlines or external/internal events
- Providing context around value delivered to the business
- Improving comprehension around KPIs, metrics, or analytics which will define project success
Mitigate risk for the business by:
- Improving understanding of cost-implementation trade-offs
- Demonstrating trade-offs between quality and timeline
- Verifying assumptions made by solutions architecture
- Articulating key business goals in terms of ROI, KPIs, and any other metric which will define project success
Risk is only mitigated 50% by planning.
Discovery is about learning about what makes the project valuable to end users and the business. An initial discovery workshop is a foundational planning session, but once you’re a few months into the project—it is easy to lose site of the big picture, and why you should build each feature.
Allow developers and stakeholders to learn continuously through agile discovery.
Instead of simply performing one foundational discovery workshop, execute a discovery workshop as part of your regular agile ceremonies. Perhaps not in every sprint, but certainly before each major undertaking of the project. I recommend a discovery workshop at least every 4 sprints.
If you disagree with this timeline, think of how well you remember meetings you had 2 months ago. Not well, right? Don’t leave the details of your project up to 2-month-old conversations—consistently bring developers and stakeholders into the story with agile discovery.
Focus on a high-resolution output by executing discovery workshops just-in-time before development.
If your development team is discovering requirements each sprint, you should be defining features each sprint.
It is a simple concept, and a powerful one. When building a product, you are actively testing each developer on the completeness of their understanding of the product vision. Would you rather give them a test after a few months have passed since your last discussion, or would you rather refresh their memory right before the test? One strategy leads to inconsistency, the other leads to consistent success.
Nurture stories on each prior sprint and educate developers and stakeholders of the expectations for the high-resolution results.
Give yourself room to reprioritize and evolve the roadmap over time. Agile discovery is backlog verification.
Why is Agile Discovery important to projects?
While we all want to build a product that looks something like this:
No imperfections, and plenty of fruit (ROI) maturing on the tree.
In reality our web development projects look a little more weathered, they’re not built in a vacuum, and they’re subject to misunderstandings, errors, and changes in scope.
A more common Feature Tree. Some valuable fruit (ROI), but plenty of features developed which don’t add value to the tree—the dead leaves will eventually fall off as they are pruned.
How does Agile Discovery consistently deliver value to the business?
With an agile discovery process, your workflow can allow for just-in-time verification of planned stories in the backlog. When verifying the backlog as a product owner, you’re looking for three things:
- User Stories / Job Stories - detailing the value delivered to the end-user or consumer of the web application.
- Acceptance Criteria - specifications detailing acceptable levels of performance and functional behavior to be developed.
- Value Story - brief description of value delivered to the business, directly or indirectly.
What is a value story?
Value stories are statements that describe the value delivered to the company. These usually come in two main categories:
- Value delivered to end-user; no direct correlation to value delivered to business
- E.g. improved user experience
- Value delivered to the business or organization; trackable with key performance indicators.
- E.g. increased pageviews per user session to drive X% growth in display ads revenue
Why are value stories important?
Value stories allow both product owners and developers to have a clear understanding on how a feature is supposed to deliver value to the business. Simply describing an improved user experience with a user story can help you deliver better features, but if your end goal is to earn a return on investment, describe what value you’re looking for out of your feature.
How do value stories correlate to business value?
For any story in which you can not clearly define a metric or key performance indicator to measure success, you likely don’t have a clear correlation between value delivered to the business and time spent in development.
These kinds of stories tend to stray from the key focus of your project and are “nice-to-haves.” Here, you should consider trimming the fat and removing them from the backlog.
In order to build a profitable business, you must define, implement, and track measurable goals for all of your features.
If you can’t track a feature’s performance after implementation... well, you might as well light your money on fire—it brings no more value to your business.
Building features whose performance can’t be tracked is like burning cash. Perhaps gambling is a better analogy here, but at least a gambler knows which game earns them the money.
In an interconnected digital world, you have every opportunity to prove delivered business value with analytics. If you’re not planning to prove delivery of value with tracking, then you’re missing the largest opportunity you have around this project.
How to execute Value Driven Development with User Story Mapping
With all this theory flying around, it is difficult to build a picture of what this will look like for your organization.
Let’s break it down.
Initial discovery workshop
Build a foundation of understanding for stakeholders and team members. Our technique of choice is User Story Mapping. It allows for an easy to understand visual map to establish shared understanding.
- Build a user story map to tell the story about how users will move through your web site or application.
- Focus on functional user flows through the application.
- Highlight stories which specifically deliver value to the business, e.g. “Implement DFP Ads”
Agile Discovery
With Agile discovery, verify scope 2 sprints ahead of delivery, keep all stakeholders on the same page, and confirm a shared understanding around the ecosystem of the product.
As a product owner, this is the perfect time to detail stories with all the criteria and validate assumptions with end users.
- Detail user stories with acceptance criteria and functional requirements
- Detail user stories with value statements describing expected value delivered to the business.
- “Implement the Announcements block to give timely updates of new content, and drive 10% additional pageviews.”
- Detail user stories with KPIs to determine the success of the story.
- “Announcement Block Click Events”
- “% Growth of Pageviews Per Session”
With agile discovery, build a high-resolution understanding of what must be developed, just in time for each sprint.
Benefits of Agile Discovery
With agile discovery in your toolbelt, you benefit from:
- Ensuring development teams always build the most valuable thing first
- Executing data-driven development instead of data-informed development
- Minimizing stories developed for outdated requirements
- Continuously delivering business value
- Small time gap between when requirements are defined and when developers review requirements
- Planning for the unexpected, by not having a plan until the week before
I need help!
Is a project getting away from you in scope and value? Facet can help you zero in on what’s most important. Start a conversation with us today, or check out some of our resources below to learn more about how we help.
