Avoid these common user story mistakes.
In this video, Frank Velazquez explains the problems associated with writing bad users stories. He provides examples of good and bad user stories and explains how writing bad user stories negatively affects Agile value delivery.
You can read the original blog article at: https://agilecheetah.com/the-real-price-of-doing-user-stories-wrong/
How you use “Agile” support tools could sabotage your agility
Table of Contents
How an organization uses “Agile” requirements management and team collaboration tools like JIRA is an indicator of how well that organization aligns its management of software systems development with Agile software development. The least “Agile-mature” organizations attempt to manage Agile projects with traditional project management biases and expectations. Such organizations often use Agile requirements management and collaboration tools to track and report:
All the while, organizational leaders and management assume they are “Agile” because they are using “Agile” tools.
Before expounding on these two general misuses of Agile requirements management and collaboration tools, let’s go over what the Agile Manifesto for Software Development says about tools. Agile values, “Individuals and interactions over processes and tools.” While Agile teams institute processes and use tools to manage their work, they value direct interaction between individuals more. Under this construct, tools are enablers that facilitate communication between team members and project stakeholders. They are not substitutes for direct communication.
Agile prefers face-to-face communication over emails, phone calls, project tools, formal boards, documentation, etc. This way of communicating increases agility by avoiding the use of intermediary channels, documentation, and reporting structures that often slow and distort communication. It also prevents formalizing decisions too early, which unnecessarily narrows options and commits development teams to approaches that may prove wrong after having spent significant time, money, and resources implementing them.
However, not every interaction in and among Agile teams can be face-to-face. Agile development teams with members who work remotely, and enterprises staffed entirely with remote teams, are common. While Agile best practice is to collocate teams and team members, it is not always possible. For example, the project team may be too large to depend solely on direct communication between members.
Agile requirements artifacts are purposely lightweight. They work as reminders for future conversations that will flesh out details. However, even lightweight requirements become difficult to manage as they grow in number. Requirements management and team collaboration tools help document and track requirements, manage work, and report progress. They also help bridge distances and time zones between collaborators.
The types of metrics relevant to traditional vs. Agile projects are different. Traditional project management is concerned with managing the constraints of the Iron Triangle: Cost / Budget, Schedule, Scope, and Quality.
Fixing the former three constraints leaves quality as the only variable, opening the door to sacrificing quality to adhere to the other constraints. We can sum up the Iron Triangle with the adage, “I can get it to you cheap, fast, or good. Pick any two.” On the other hand, we manage Agile projects primarily by managing scope. We fix schedule and budget while treating project scope as variable and not sacrificing quality.
Keeping the first three constraints of the Iron Triangle fixed throughout a project requires adherence to detailed project plans. Changes to those plans are highly frowned upon since even small changes can ripple across project plans in unexpected ways. Thus, traditional project managers focus on managing people and tasks to keep projects on track with plans. This leads to collecting metrics such as the ones shown in Table 1 below:
Agile projects hold schedule and budget fixed while treating scope as a variable. In essence, we have a span of time, a bucket of money, and the flexibility to build just enough of what is needed to satisfy customers. When schedule or budget run out, we can stop development or pony up more money to build more. We also have the flexibility to stop the project at any time should we decide that we delivered enough functionality or if the project is no longer viable. Cancelling a failing or unnecessary project after spending $10 million is much better than doing so after spending $100 million.
Since Agile teams are self-organizing, they manage their own work. They do not need management to allocate tasks, lead estimation activities, or coordinate between teams. Also, in Agile, “Working software is the primary measure of progress.” Therefore, metrics like percentage complete are unnecessary (and nonsensical) since we regularly evaluate complete and releasable business or mission functionality. In Agile, a feature is either done or it isn’t and teams do not take credit for work on incomplete features. What “complete” means to project teams and stakeholders makes up the “Definition of Done”.
“Agile metrics” help teams:
Many Agile approaches / frameworks exist. In the Table 2 below, I provide Scrum metrics and reports as examples. I avoid discussing the details of tracking, reporting, and using these metrics and reports in this article. Instead, I present these examples to drive home the point that what we measure, track, and report in Agile projects is different from that of traditional project management because the two approaches are fundamentally different.
Measuring the quality of deliverables and acting on findings is crucial to all software development projects, Agile or not. There aren’t Agile-specific measures of quality. However, like traditional requirements, well-formed Agile requirements specify the outcomes and quality characteristics associated functionality must meet. In Scrum, for example, quality criteria inform user story acceptance criteria.
Many organizations configure and use tools like JIRA to collect and report traditional project management metrics. This practice demonstrates a fundamental misunderstanding of Agile and how it differs from traditional project management. It is also indicative of organizations that adopt the terminology and mechanics of an Agile approach or framework without embracing its principles. While tools can enable Agile practices, agility is not the result of using tools.
Tools like JIRA are primarily designed to support Scrum teams. As such, they organize work through product backlogs. A product backlog is a prioritized list of estimated or “sized” descriptions of business or mission capabilities needed by users or roles (human or automated) to accomplish specific outcomes. Scrum teams typically write these requirements as user stories:
We write user stories from the user’s perspective, not from the perspective of the system we are building or the tasks developers need to do.
Unfortunately, it is quite common to see user stories written as system components or deliverables or as developer tasks. Many teams also neglect to size and prioritize product backlog items until sprint planning (and sometimes not at all). Rather than managing a product backlog, such teams work from what is ostensibly a to-do list. Doing so takes away the ability of Scrum teams to manage current work, plan future work, and clearly communicate project status.
Requirements management and team collaboration tools like JIRA are useful for documenting and tracking requirements, managing work, and reporting progress. However, using such tools is not the same as being agile, especially when used to support traditional project management processes and reporting. Understanding the differences between Agile approaches and traditional project management is key to ensuring we avoid contorting Agile to support Waterfall processes and expectations.
Two very different ways of managing project scope
This is the third and final video of a series that explains and compares the Work Breakdown Structure (WBS) and Scrum’s product backlog. In this video, Frank Velazquez compares and contrasts the two artifacts and how they support very different approaches to project scope management between traditional project management, or Waterfall, and Agile. This understanding is crucial for viewers implementing Agile in organizations steeped in traditional project management.
An infographic to help your team understand the difference between functional and non-functional requirements (NFRs)
