Very early in my development career I learned an invaluable lesson: entities such as Agencies, Customers, and End Users do not have ‘requirements’.

They have needs.

Business analysts or Product Owners (or other requirements specifiers) need to identify the requirements from these needs.

Requirements ‘Fill-in’ the Needs

Consider this example fragment of a ‘need’:

          “When a member is eligible for benefits I have to…”

Requirements probing should result in answering:

• What constitutes a member?
• Can a member have different states?
• What are the criteria for changing a member state?
• What behaviors and business rules are associated with each member state?
• What constitutes eligibility? Are there different types of eligibility?
• What is a benefit? Are there different kinds of benefits?
• What are the possible relationships between a member and benefits?
• ….

Requirements Types

If we aspire to be effective Scrum Masters, we must not embrace the misconception that requirements are monolithic and have a single representation.

Here is a partial litany of different types of requirements:

• Business
• Functional
• Non-functional
• User
• Security
• Performance
• Reliability
• and many more…

Formats for Requirements

The representation or presentation of a requirement is determined by the type of that requirement.

Static relationships among Entities
Class diagram, Context diagram

Interaction Among Entities
Sequence diagram, Communication diagram, Timing diagram, BPMN

Behavior (for example, business rules) of an Entity
State Machine diagram, UI mockups, Flow Diagrams

Interactions between a Requestor and a Provider Interface
Use Case, Use Case diagram, Sequence diagram

Overview of Functional Goal, Data Mappings
Textual narrative, Data transformation tables, DB Schemas

But What About Stories?

Stories are often viewed as sufficient to convey requirements.

This is not a correct perspective.

Stories are the beginning of a journey to obtain the requirements. At the beginning of The Agile Era, Ron Jeffries expressed this as, “Card, Conversation, Confirmation.” That is, stories are placeholders for a conversation between the business and technical constituencies to reach a shared understanding of what really is required in the solution.

Stories were introduced in Extreme Programming:

• To be easily managed and prioritized
• To limit work so developers could obtain rapid feedback
• To allow us to prove our progress on a regular cadence (sprint)
• To eliminate distractions about our delivery goal
• To allow us to arrange requirements and their development into cohesive fragments that have economic or other value

But stories are only one aspect of a larger geography of work items we embrace in agile projects.

Feature, Story, or Task?

In my 30 years of Agile, every one of my clients has struggled with how to distinguish a task from a story, and so forth.

The Truth: Making this categorization upfront can be a losing battle.

The Reality: You have LITTLE THINGS and you have BIGGER THINGS.

The Process:

• Just describe or define the ‘thing’ and how it will meet a customer or business need.
• If it is business-value oriented and it will take multiple sprints, it is a Feature (a few sprints) or Epic (very many sprints, or multiple releases)
• If it is business-value oriented and fits in one sprint, consider it a Story.
• If it is a short-lived technical activity, it is a Task. Done.

Semantics or Purpose of Each Work Item Type

The work items we categorize in most agile projects reside across several levels which differ in scope and precision of specification.

Task, or sub-task
A technical activity which enables the delivery of the business goal in a story. End-users or customers never ask for a Task.

Story (user)
A relatively small, non-technical goal to satisfy a user or organization need. The goal could be new functionality, or an enhancement of existing user-oriented functionality.

Story (defect)
A description of a deviation from a stated requirement.

Story (bug)
A run-time defect.

Story (system)
A technical goal to enable other process or product improvement.

Story (spike)
An activity to gain knowledge or reduce uncertainty, not to produce additional functionality.

Feature
A relatively large business goal to benefit the organization or its stakeholders. A feature description would be appropriate in a marketing advertisement. End users or customers might express their need as a feature. The distinction between story and feature is not always self-evident, and often is decided by the time required for the implementation.

Epic
A broad, long-term and strategic goal to guide delivery of tactical business benefit through application of process and technology.

The following diagram conveys the 3-dimensions needed to characterize each of the work item levels.

We must not only use the best format for our work items, but we must know what level of scope and precision we need to represent. Developers spend most of their energy on stories and tasks. Product Owners and business partners live in a world of features and stories, while executives and business owners will focus on epics or even higher artifacts such as value stream maps.

I hope this brief review of these basic concepts on work item hierarchy will simplify how you populate and manage your backlogs for your developers, your business partners, or your executives.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.