Whitepaper
Why User Stories Fail and How to Jumpstart your
Stalled Agile Transition
blueprintsys.com
Why User Stories Fail and How to Jumpstart your Stalled Agile Transition
Whitepaper
User stories are the core artifacts used to represent software requirements in Agile. They are simple,
textual artifacts describing user needs with “just enough” information so development teams can
estimate effort, manage tasks, and measure progress.
When written well, user stories are powerful; they help the team view requirements from an end
user’s perspective. Unfortunately, however, they aren’t enough to fully represent requirements in
large, distributed organizations with complex projects, as they attempt to shift from traditional to Agile
practices.
The Sad Truth About User Stories in Real-World Enterprise Agile
As teams have tried to switch from text-heavy, cumbersome Business Requirements Documents
(BRDs) to user stories, they’ve hit some serious challenges. In almost all organizations:
User stories are
often of poor quality.
Business stakeholders
and BAs have never
written them, and just
as with learning a new
language, it takes
time to get used to
the vocabulary and
composition. User stories
end up being incomplete,
inconsistent, or missing
altogether.
blueprintsys.com
•
Traditional requirements practices are deeply embedded. The BRD has been used
for decades. And yes, it has its shortcomings, but it’s familiar. Most of the people involved in
requirements – primarily business stakeholders and Business Analysts (BAs) – are new to Agile.
They don’t “get” user stories and hesitate to give up the BRD for something so different.
•
Projects are too large and complicated. These teams are trying to deliver software in
convoluted, rapidly-changing business and technology environments. Dozens (sometimes
hundreds) of people need to be involved, there is lots of risk, and organizations need certain types
of documentation to facilitate sign-off and manage real-world constraints. User stories alone simply
don’t scale to meet the needs of today’s enterprise projects.
•
Requirements authors don’t have the right tools. Most Agile development teams use an Agile
task management tool, like JIRA or VersionOne. Ultimately, that’s where user stories need to end
up to be decomposed into development tasks. Most business stakeholders and BAs, on the other
hand, still use Microsoft Word and Excel to author requirements. Even if user stories were easily
adopted and could address enterprise needs, this tool mismatch stymies the cross-departmental
collaboration teams need to realize Agile’s benefits.
As a result, when teams try to represent requirements through user stories alone:
•
User stories are often of poor quality. Business stakeholders and BAs have never written
them, and just as with learning a new language, it takes time to get used to the vocabulary and
composition. User stories end up being incomplete, inconsistent, or missing altogether. Add to that
the fact that many critical aspects of requirements, like non-functional requirements and business
rules, don’t fit well into the user story construct. This further impacts user story quality.
•
Requirements still take too long to deliver. Requirements in the average enterprise project
need input from many stakeholders. They almost always involve complex legacy systems, which
are commonly undocumented. A project of any size can require hundreds – or even thousands – of
user stories. It can take as long to develop them as it does to create a BRD. Organizations aren’t
realizing the speed they thought they would with Agile.
•
They find they need more. Not only do they fail to adequately describe non-functional
requirements and business rules, user stories are textual. They need the support of visual artifacts,
like process flows and mockups, and related documentation, like regulatory documentation
and company policies, to provide a complete picture of requirements. Without easy access to
supporting information, people fail to understand requirements fully.
2
Why User Stories Fail and How to Jumpstart your Stalled Agile Transition
Whitepaper
The false hopes that Agile with its user stories would replace the BRD have been dashed, Agile
transition has stalled, and organizations are trying to figure out what to do next.
How can Enterprises Align Traditional Preferences with Agile Needs?
To kick their Agile transitions back into gear, enterprises need a way to align traditional requirements
and Agile user stories and the people that create and consume them. To do so in the most effective
way, they must recognize and account for the indisputable facts that most of the people responsible for
requirements:
•
Are new to Agile.
•
Don’t know how to write user stories.
•
Live daily in Microsoft Office.
On the other hand, most development teams:
Many organizations get
“stuck” in their Agile
transitions, because no
matter how hard they
try, they’re still unable
to reconcile these
differences between
traditional and Agile
worlds and the people
who live in them.
blueprintsys.com
•
Use Agile techniques every day to do their work.
•
Need user stories to derive tasks and tests.
•
Live daily in an Agile task management tool, like JIRA.
Many organizations get “stuck” in their Agile transitions, because no matter how hard they try, they’re
still unable to reconcile these differences between traditional and Agile worlds and the people who live in
them. So how do they get “unstuck” and kick their Agile transition back into gear?
Process models align traditional and Agile requirements.
You can’t do Enterprise Agile well unless you have modern technology to support it.
Why? In many ways process models and user stories are similar. Not only are they both used to
describe software requirements, they also:
•
Represent a journey. Both have a beginning, a middle, and an end. A process model, with
its starting point, roles, actions, conditions, decision points, pathways, and end points, paints a
picture of how a user and system interact to complete a process. A user story does so also, with
its textual representation of a story: “As a who, I want to what, so that why.”
•
Represent interactions from the user’s perspective. With an increased focus on customer
experience (CX) and user experience (UX), teams are seeking to view requirements through the end
user’s eyes. Process models and user stories both help them do this, so teams can gain a solid
understanding of how users will experience the product they deliver.
•
Give developers and testers information they need. While requirements can rarely be
represented solely in the form of process models or user stories, both provide the development
team with information they need to develop and test functionality as part of a software
development project.
3
Why User Stories Fail and How to Jumpstart your Stalled Agile Transition
Whitepaper
When it comes to representing requirements, however, process models have an advantage, because
they are:
•
Familiar to all. Virtually all business and technical stakeholders know how to create and
comprehend process models. They use them frequently to visualize business and technology,
inform decisions, and improve processes. Process models are written in a shared language.
•
Visual. The best practice of visualization – the use of models, like process flows, mockups,
and prototypes – boosts collaboration, improves understanding, and leads to more complete
requirements than text alone. Everyone engages to develop a shared understanding.
•
Flexible. Teams can flexibly model processes with “just enough” detail to meet their needs.
Process models can be used to describe high-level and more detailed processes from both user
and system perspectives. They can be inter-related to represent the hierarchies of processes
and sub-processes. They can be augmented with text and color-coded to add information. Their
variations are virtually endless, yet they are still intuitively understandable.
•
Simple to construct. People have been using Microsoft Office and Visio for decades to create
process models. And most modern requirements tools that support visualization, including
Blueprint, use similar, simple, drag-and-drop interfaces for diagraming processes.
User stories come to life when paired with a process model.
Process models and user
stories complement each
other. They also relate to
one another in a powerful
way that organizations
can leverage to align
traditional and Agile
requirements.
Process models and user stories complement each other. They also relate to one another in a powerful
way that organizations can leverage to align traditional and Agile requirements.
Bottom line, process models, with their multiple steps and pathways, represent a collection of user
stories. When you analyze a well-written process model, it is clear that:
•
Its roles translate to a user story’s who – the person, role, or system performing an action.
•
Its tasks translate to a user story’s what – the action or goal of the user story.
•
A user story’s why can be derived from downstream tasks or the outcome of the process.
•
Pre-conditions, post-conditions, and system responses translate to a user story’s acceptance
criteria.
With a set of well-written, hierarchical process models representing an end user journeys, teams
can easily analyze and decompose processes into individual user stories fit for consumption by the
development team. The user stories also end up being of higher quality, because they’re:
blueprintsys.com
•
Connected to a bigger picture. A link is established between the organization’s high-level
business strategies, processes and sub-processes, and lower-level development tasks. The
development team can see user stories in context, which leads to a better understanding. This
connection also enables improved impact analysis and change management through upstream
and downstream traceability.
•
Influenced by a broader community. Visualization engages people, so business and technical
stakeholders are more likely to get involved. The shared language of process flows enables
everyone to review requirements and provide feedback. It’s less likely that key stakeholders or
valuable corporate knowledge will be missed.
•
Easier to write. The information needed to write user stories is contained in familiar visual models
people can easily understand and convert to well-written Agile requirements artifacts. Process
models also provide a framework for organizing them.
4
Why User Stories Fail and How to Jumpstart your Stalled Agile Transition
•
Whitepaper
Easier to understand. Business people can reference familiar process models to better
understand how user stories were derived. Technical people have more information from which to
draw on when creating and managing their work tasks. Over time, everyone becomes more The
false hopes that.
Technology Speeds the Delivery of High-Quality User Stories
Storyteller enables
a diverse set of
business and technical
stakeholders to
collaborate in a shared
workspace to define
process models. These
models are created
easily in an intuitive,
drag-and-drop interface
most people can use
without training.
Using process models to derive and organize user stories helps companies improve requirements
quality and business-IT alignment. It also aligns traditional and Agile practices, ultimately easing the
transition to Agile.
Unfortunately, however, writing user stories can still take an enormous amount of time. Even if you
already have a set of stellar process models, someone has to analyze and decompose them into
individual stories and then manually create them in another tool – for example, Microsoft Word or the
development team’s Agile task management solution.
For a large, complex project with hundreds of user stories, this is not just resource-intensive, it is highly
prone to human error. So while pairing process models with user stories improves user story quality, it
does little to accelerate their delivery.
To reinforce and speed up new Agile processes, teams need technology to support them. Agile
frameworks and training address people and process changes, but fail to address the fact that, to scale
Agile, organizations need tools to “crystalize” the process and automated the huge quantity of manual
tasks. This is incredibly critical in large, distributed organizations with high-dollar portfolios, regulatory
constraints, and complex technology. Blueprint Storyteller for Agile is a revolutionary solution that meets
these needs.
First, Storyteller automates the collaborative creation of robust process models.
Storyteller enables a diverse set of business and technical stakeholders to collaborate in a shared
workspace to define process models. These models are created easily in an intuitive, drag-and-drop
interface most people can use without training.
Using the familiar construct of process models – with tasks, decision points, users, and condition
statements – and robust collaboration capabilities, including threaded discussions and email-driven
interactions, everyone stays in sync. Teams are able to focus on business strategy and processes – not
a long list of user stories – when defining software requirements.
Then, Storyteller auto-generates quality user stories and tests with one, simple click.
Storyteller uses teams’ collaboratively-defined process models to automatically generate user stories,
including their acceptance criteria, along with test cases in a CSV format or as Gherkin feature files – all
with the click of a button.
Storyteller pushes these artifacts into the development teams’ Agile management tool of choice, where
developers and testers also have access to the process models on which they are based and related
information, like regulatory documentation, other visual models, non-functional requirements, and
business rules. This gives them a view of the bigger picture, boosting analysis and understanding.
blueprintsys.com
5
Why User Stories Fail and How to Jumpstart your Stalled Agile Transition
Whitepaper
Because user stories are automatically-generated, human error is removed from the equation. They are
complete and consistent. They cover all process scenarios and conditions. Organizations no longer
have to spend time and money teaching business stakeholders and Business Analysts how to write
them.
Storyteller keeps everyone on the same page.
With Storyteller, bi-directional synchronization with leading Agile task management tools, like JIRA
and VersionOne, keeps requirements information up-to-date as change occurs. Stakeholders can
collaborate to author, review, and provide input on requirements in the tools they are most familiar with,
improving their productivity. Storyteller even generates the traditional documentation many organizations
need for sign-off and filing to track compliance with regulations and business policies.
Storyteller’s key features and benefits:
Storyteller gives the
people who author
requirements the ability
to create complete,
consistent user stories
quickly and easily,
without training, and
without having to use
the development team’s
Agile tools.
•
Enhanced enterprise collaboration and communication for a broad range of users, of any skill,
across the organization.
•
Improved business-IT Alignment through the use of collaboration, visual modeling, and the
connection of development and test artifacts back to high level processes.
•
Faster delivery of Agile requirements through auto-generation of user stories, acceptance criteria,
and tests in an intuitive “Given-When-Then” format.
•
Significantly improved quality, consistency, and coverage of user stories.
•
Elimination of the need to train those new to Agile on how to write good user stories.
•
Use of online collaboration through threaded discussions and email-driven conversations.
•
Bidirectional synchronization of Agile requirements artifacts with the development team’s task
management tool of choice, eliminating the need to manually create them.
•
Auto-generation of documentation for sign-off or filing to meet regulatory compliance and policy
requirements.
Where the Story Ends and Agile Transition Begins
Blueprint Storyteller for Agile gives the people who author requirements the ability to create complete,
consistent user stories quickly and easily, without training, and without having to use the development
team’s Agile tools.
Storyteller is a robust, enterprise-ready Agile requirements tool that aligns business and IT. It speeds
delivery while managing enterprise constraints. And it enables organizations to get “unstuck” – to scale
Agile across the enterprise, so they can reap its benefits while managing complexity and risk.
90 Eglinton Ave E #700
Toronto, ON M4P 2Y3, Canada
1.866.979.BLUE(2583)
www.blueprintsys.com
BP281881 30-Mar-2017
Blueprint provides industry-leading solutions that accelerate and de-risk the digital transformation of large
organizations. With our products - Blueprint Storyteller for Agile, Blueprint Automate for DevOps and Blueprint
RegTech for Compliance - organizations receive greater business value from IT, faster and more frequently, while
dramatically increasing the efficiency and confidence of compliance.
© 2017 Blueprint Software, Inc. All rights reserved. All product and company names and marks mentioned in this
document are the property of their respective owners.
6