There are many ways to document requirements in today’s technocrat world; however in agile centric projects crafting requirements (so called User Stories) have become the popular and preferred method. While not exclusive to an agile methodology, User Stories can help to express requirements in terms of the business value they provide.
Numerous Agile business analysts are hesitant to employ certain requirements elicitation and development techniques such as user stories and use case studies because they are traditionally considered aspects of the Waterfall or traditional method of Project Management. However, the overwhelming responsibility of the business analyst, no matter what method is being used, is to help stakeholders identify their needs and translate them into requirements. Both use cases and user stories should be leveraged to determine the most appropriate business solution to bring value to the customer.
I have been using User Stories in Agile projects since quite a while now; however never thought of defining the composition of user stories, until one of my dear friend Mr. Abhijit Chaudhuri knocked my mind asking below queries.
- How to utilize User stories in software testing process / production support?
- Is there any standard process flow to implement/introduce User Stories?
- If yes at what stage users stories need to be develop / create, in terms of Software Test life cycle?
- Is there any general Standard template for writing User Stories for Software Testing?
Herewith I have tried to provide inputs around the above queries on “User Stories”
What Is A User Story?
A user story represents a small piece of business value that a team can deliver in iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:
- The brief description of the need
- The conversations that happen during backlog grooming and iteration planning to solidify the details
- The tests that confirm the story’s satisfactory completion
Why Use User Stories?
- Keep expressing business value
- Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
- Avoid the appearance of false completeness and clarity
- Get to small enough chunks that invite negotiation and movement in the backlog
- Leave the technical functions to the architect, developers, testers, and so on
What Size Should A User Story Be?
A story should be small enough to be coded and tested within an iteration, when a story is too large, it is called an epic. Backlog items tend to start as epics when they are lower priority. For release planning, epics should be broken down into smaller chunks, but not so small that you have moved into detailed design.
How Detailed Should A User Story Be?
- A team member can view iteration status.
- A team member can view a table of stories with rank, name, size, package, owner, and status.
- A team member can click a red button to expand the table to include detail, which lists all the tasks, with rank, name, estimate, owner, status.
- A team member can view the iteration’s stories and their status with main fields.
- A team member can view the current burndown chart on the status page, and can click it for a larger view.
- A team member can view or hide the tasks under the stories.
- A team member can edit a task from the iteration status page.
Principles – Agile requirements
- Design a process for collaborative requirements gathering upfront
- Identify and engage a product owner and knowledgeable SMEs
- Acquire effective facilitation/elicitation and visual modeling skills
- Break down/slice requirements to the right level
- Focus on breadth early, on depth later
- Define ‘Acceptance Tests’ as part of the requirement
- Refine the Stories until They are Ready
- Keep user stories visible and accessible
- Requirements must be “Just in Time” detail
- Requirements must be “light” enough
- Requirements must be “Assumes” change
- Requirements must be “Estimated” in points
- Requirements must be “Prioritized” top down
- Requirements must be “Crafted/gathered” collaboratively
- Requirements must be “Focus on” breadth
Characteristics of User Stories
- They are short and easy to read
- They are captured in a “list format” large BRD’s not welcome here!
- They can be discarded after implementation
- They represent small increments of functionality
- They should be relatively easy to estimate
- Detailed system behavior is NOT captured in a user story
Use Personas to Discover the Right Stories
A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product.
Who Uses User Stories?
Creation: The customer, customer proxy, product owner, and anyone else who identifies a need for the product can contribute user stories.
Ownership and maintenance: The product owner owns the user stories and is responsible for writing, gathering, maintaining, and prioritizing.
Usage: Developers, testers, technical writers use user stories to be able to know what to implement and when they are done. Product owners track overall progress based on the status of the user stories. Management tends to track user stories rolled up to epics or features.
What are the challenges you face when it comes to writing good requirements?
- Think breadth then depth
- Break it down into small chunks
- Following INVEST (Independent, Negotiable, Valuable, Estimate-able, Small, Testable)
Lifecycle of User Story
Agile Requirements Elicitation Techniques
- User Roles, Personas
- Use Cases Diagrams
- Process Diagrams
- UI Flow Diagrams
- Context Diagrams
- Group Brainstorming
- Facilitator Led Callout
- Post-it Note
- Story Mapping
- Silent Sorting
Breakdown / Slicing
- Business Rule
- Process Steps
- Acceptance Tests
- Test Scenarios
- Example Tables
- UI Prototyping and Wireframes
- Business Rules
- Activity Diagrams