Keeping the Focus on Value, Not Output: A Scrum Team Story
In Scrum, the purpose of every Sprint is to deliver value to customers and to the organisation. Velocity -- the number of story points completed per Sprint -- is a useful internal planning tool, but it is not a measure of value. A team with high velocity that is building the wrong thing, or building the right thing for users who cannot access it, is not delivering value.
The following scenario describes a pattern that is more common than most Scrum teams recognise.
The Scenario: A Digital Services Team
A Scrum team at a provincial government agency is developing an online permit application service. The team has a strong velocity of 42 story points per Sprint. They have shipped every Sprint for six months, completing 1,008 story points over that period. The retrospectives are positive. The team's Definition of Done is rigorous. In April 2022, the agency conducts a user research study and discovers that 78 percent of permit applicants are still using the paper form rather than the online service. Of the 22 percent who attempted the online service, 60 percent abandoned before completing the application. The online service has been fully functional and technically correct for four months.
What Went Wrong
The Sprint Goals were feature-delivery goals, not outcome goals. Every Sprint goal read something like "complete the payment integration module" or "implement the document upload feature." None of the Sprint goals referenced user adoption, completion rate, or transition from paper to online.
The Product Backlog was a feature list, not a prioritised value delivery plan. The Product Owner had ordered the backlog by technical dependency and estimated complexity rather than by expected user impact. Features that addressed the primary barrier to adoption -- a confusing navigation structure identified in an early user test -- were deprioritised because they were "UX work" rather than "feature delivery."
The team had no connection to usage data. No one on the team was tracking how many users were attempting the service, how many were completing it, or where they were abandoning. The Definition of Done included technical testing but not any measure of accessibility or usability in the real environment.
The Product Owner had no feedback loop from real users. The Sprint Reviews were attended by internal stakeholders, not by the applicants who would use the service. Feedback from internal stakeholders consistently confirmed that the features were technically correct, not that they were meeting user needs.
What They Changed
The team reformed around outcome-based Sprint Goals (target adoption rate, completion rate), added a usage analytics instrument to the Definition of Done, established a monthly user interview programme, and restructured the Product Backlog by the barriers to adoption. Over the following three Sprints, velocity dropped from 42 to 31 story points -- because UX remediation work was less predictable than feature delivery. But the completion rate increased from 40 percent to 68 percent, and paper form usage dropped by 25 percentage points. The team was delivering less output and significantly more value.
XNM supports public-sector organisations in building outcome-focused Scrum practices. Reach out to XNM's program & project delivery advisory team to discuss value-focused agile delivery for your digital programme.