How Working Tested Product Improves Business Outcomes
Desired business outcomes are unique to each organization or business. They depend on the software or product they produce and their audience or market. The goal of adopting Agile is always about achieving the desired business outcome unique to the organization that is pursuing it.
The six most common desired business outcomes are:
- Predictability
- Improved Quality of Software or Product
- Cost Savings
- Early ROI
- Product Fit
- Innovation
If you can’t regularly produce a working tested product, you likely won’t reach any of these desired outcomes. Being predictable requires knowing how long it takes to complete work. Improving the quality of your product requires testing, releasing to market, and updating based on customer feedback. Cost savings and early ROI can’t happen if you’re losing time to development and not taking care of defects along the way. Product fit and innovation can only be addressed if you keep up with your market needs and anticipate what’s next.
And whether you are producing software or some other product, the process can be applied to many different contexts. The Agile mindset can be adapted to fit many industries or businesses. The term working tested product expands the scope of what Agile can do; it’s more general and can be used to explore what it means in any business context. Agile Transformation can go beyond software development and improve any organization’s operations to achieve its desired business outcomes.
The Process of Producing Working, Tested Product
Product owners and their teams are responsible for creating and managing backlogs and validating the work produced. They are responsible for defining the user stories and prioritizing the backlog to execute program requirements. They are the ones that must define clear acceptance criteria and definition of done.
From a process perspective, like in Scrum, the product owner brings the backlog to the Scrum team, and they accept the work into their sprint. This means they know the scope of what’s required, how to complete it, and when it needs to be delivered. They can negotiate the amount of work they accept into their sprint during sprint planning based on their team’s past velocity. Work is then incrementally completed and kept track of through daily stand-up meetings, and the sprint is reviewed afterward to see what can be improved next time.
During the sprint, work is validated by the product owner to ensure that it is on the right track or if it needs to be adapted. The constant loop of development and testing prevents work from getting too far without knowing if it’s performing right. In the end, this saves time in releasing the product and reduces the number of technical defects that could be present.
Getting to a Definition of Done
A working tested product is something that can be confirmed or tested and has a clear definition of done that can be met. Typically, the definition of done is defined by user stories that are features or desired outcomes for the end user, customer, or consumer of the final product.
User stories are accepted into the backlog and require clear acceptance criteria, a pre-decided behavior the increment needs to exhibit. With clear acceptance criteria and definition of done, the development teams know precisely what work must be finished by the end of the designated time period or sprint.
Being able to meet a definition of done and have a potentially shippable product at the end of each sprint means that developers can fix defects as they show up, and customer feedback can be addressed faster. Products can be released to market sooner or more regularly, allowing organizations to adapt in real-time to market demands and customer needs.
Avoid Pushing Work to the Next Sprint
The process of getting to a definition of done at the end of the sprint is essential because if you do not, you end up with an indeterminate, invisible backlog of work behind the delivery of user stories. In other words, you’re producing work much slower than you think.
For example:
- You have 1000 story points in the backlog.
- Delivery is 200 story points per sprint, so it will take five sprints to complete the backlog.
- You think you deliver 200 points every sprint but also put 150 points back in.
The 150 points create indeterminate work, such as re-work, defect remediation, and technical debt. You may know that you have 150 extra points, but if this process continues, you’re in a cycle of never actually completing your backlog of work.
When the delivery rate of work is slower than you think, it messes up the team’s velocity. Velocity is an important metric to know how much work can be completed in a specific time. If you always have invisible work and unfinished user stories, you’ll never establish a regular velocity, and your adaptability and predictability will suffer.
On the other hand, a well-articulated backlog, stable velocity, and precise definition of done get you to a linear burndown chart throughout the sprint. This ensures that work is completed in small increments, and the product is tested and approved by product owners. Then, the team can move on to new work at the beginning of the next sprint—instead of continually dragging pieces of projects from one sprint to the next.
How Testing Drives Better Business Outcomes
One of the foundations of Agile is consistently producing a working, tested increment of software or product.
The ability to produce increments of working tested software allows developers to be adaptable to respond to shifts in requirements, work out technical problems along the way, and provide a product at the end of the predetermined period that can be presented to a client or customer and work. It gives an organization time to receive and respond to customer feedback, improving each iteration of the software or product.
Over time, developing this regular cadence enables the organization to drive toward its desired end state.