Skip to content

Define Work Item Types & Hierarchies

Define Work Item Types & Hierarchies

Definitions & Templates

### EPIC

### FEATURE

### USER STORY

Introduction

User stories have evolved from agile processes and ideologies. A pivotal moment for agile was when seventeen individuals representing different frameworks met in Utah to find common ground in the methods, they found most valuable in building software (Agile Alliance, 2001). From this meeting, the Agile Manifesto was created. Agile is the mindset that software should be built in a flexible and collaborative nature, centered around customer/market needs. As described by Agile Alliance, “One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together” (Agile Alliance, n.d.).

Principles of User Stories

User stories can vary between teams; however, certain principles must remain consistent: * Created from the perspective of the user * Facilitate conversations to solve customer problems * Criteria to determine whether the stories have been completed or not

Common Template

A common template for identifying a user story is:

As a <who>, I want <what> so that <why>

This template facilitates future discussions and is written from the customer's perspective, demonstrating the value it provides.

Example:
As a project manager, I want to generate a weekly status report so that I can keep stakeholders informed of project progress.
Acceptance Criteria

A common method for detailing the acceptance criteria is:

Given (context), When (action), Then (outcome)

This structured method helps the software team understand what needs to occur to pass and provides clear direction for creating test cases.

Example:
Given a user is logged in, When they click on the "Generate Report" button, Then a PDF report is generated and downloaded.
Non-Functional Requirements

Non-functional requirements can be described using the same template:

As a <who>, I want <what> so that <why>

As mentioned by Mike Cohn from Mountain Goat Software Blog (2023), non-functional requirements can be thought of as constraints to the system. For example, a software product must run on Safari, Chrome, and Edge. This puts limitations on how the team must develop the solution; however, these non-functional requirements can still be described using the user story template.

Example:
As a UX designer, I want to use this software on Safari so that I can use my default browser on Mac.
I.N.V.E.S.T. Criteria

When creating a user story, follow the I.N.V.E.S.T. criteria: * Independent: Can be deployed separately with minimal to no dependencies. Often described as a vertical piece of functionality. This means that a user story must include all pieces to make something functional, front-end, backend, database changes, etc. (Agile Alliance, n.d.) * Negotiable: Able to be discussed and refined with stakeholders. * Valuable: Must articulate the value it will provide to the user. * Small: Must be completed within a sprint. * Testable: Can be easily verified and tested.

Example:
As a user, I want to reset my password so that I can regain access to my account if I forget it.
  • Independent: This story can be implemented without dependencies.
  • Negotiable: Details can be discussed with stakeholders.
  • Valuable: Provides a critical function for user access.
  • Small: Can be completed within a sprint.
  • Testable: Can be verified by testing the password reset functionality.
Additional Tips for Writing User Stories

Mike Cohn provides several tips to help develop good stories: * Start with Goal Stories: Focus on the goals of a user to begin story writing. * Slice the Cake: Split user stories into vertical pieces to deliver a small piece of functionality. * Write Closed Stories: There must be a clear end to close a story. * Put Constraints on Cards: State limitations or additional constraints that may impact the user story. * Size the Story to the Horizon: Stories should become more refined as they approach the current iteration. * Keep UI Out as Long as Possible: Focus on the user and the goal they are trying to achieve. * Some Things Are Not Stories: Not everything can be expressed as a user story, and that’s okay. * Include User Roles/Persona in the Stories: Helps keep the user and the value at the center * Write for One User: Keeps the goals clear and simple * Write in Active Voice: Example: "A Job Seeker can post a resume." * Do Not Forget the Purpose: Keep the larger picture in mind.

Examples:

  • Start with Goal Stories:

    As a job seeker, I want to upload my resume so that I can apply for jobs.

  • Slice the Cake:

    As a user, I want to filter job listings by location so that I can find jobs near me.

  • Write Closed Stories:

    As an admin, I want to approve user registrations so that only verified users can access the platform.
Spike Work Items

A spike can be defined as, “a time-boxed research activity that helps teams make better decisions & deliver better products. Put more simply, a spike is an activity a team performs to get smarter about something” (Cohn, n.d.). Spikes should be time-boxed, and after the timebox period, a decision should be made if enough information was gathered or if more time is needed.

Example:
As a developer, I need to research the best database solution for our application so that we can handle large volumes of data efficiently.
Backlog Management and Estimation

The responsibility of backlog management, prioritizing work items, review, and planning with the team belongs to the Product Owner. Estimation occurs during review and planning sessions using the modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. Estimates must come from the development team, not product owners or product managers (Cohn, 2004).

User Stories vs. Other Documentation

According to Mike Cohn from User Stories Applied for Agile Software Development (2004),

User stories are not: * IEEE 830 Software Requirement Specifications: Example: "The system shall allow a company to pay for a job posting with a credit card." * Use Cases: Typically large in scope and focus on system-related actions. * Scenarios: Typically large in scope and cover many user stories.

User stories are: * A method to facilitate conversation. * Comprehensible as opposed to specification documentation. * Promote iterative design.

Examples:

  • User Story:

    As a job seeker, I want to receive email notifications for new job postings so that I can apply quickly.

  • Use Case:

    The system shall allow users to subscribe to email notifications for new job postings.
Practical Applications and Examples
Microsoft Engineering Playbook Example

Each User Story / Product Backlog Item should be sized so that they can be completed within a sprint. Include the following details: * Title: "As a [persona], I want [to perform an action], so that [I can achieve an end result]." * Description: Provide enough detail to create a shared understanding of scope and support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Provide enough details so the team can write tasks and test cases to implement the item. * Acceptance Criteria: Define what "Done" means. * Activity: Deployment, Design, Development, Documentation, Requirements, Testing. * Effort / Story Points / Size: Relative estimate of the amount of work required. * Business Value: Priority of an item compared to other items of the same type. * Original Estimate: The amount of estimated work required to complete a task.

Example:
Title: As a user, I want to reset my password so that I can regain access to my account if I forget it.
Description: The user should be able to request a password reset link via email. The link should allow the user to set a new password.
Acceptance Criteria:
- Given a user is on the login page, When they click "Forgot Password," Then they should be prompted to enter their email address.
- Given the user enters a valid email address, When they submit the form, Then they should receive an email with a password reset link.
- Given the user clicks the reset link, When they enter a new password, Then their password should be updated, and they should be able to log in with the new password.
Activity: Development, Testing
Effort / Story Points / Size: 5
Business Value: High
Original Estimate: 8 hours
References

Agile Alliance. (n.d.). Agile 101. Retrieved from https://www.agilealliance.org/agile101/

Agile Alliance. (n.d.). INVEST. Retrieved from https://www.agilealliance.org/glossary/invest/

Agile Alliance. (2001). Manifesto for agile software development. Retrieved from https://agilemanifesto.org/

Cohn, M. (n.d.). Agile Spike Definition. Mountain Goat Software. Retrieved from https://www.mountaingoatsoftware.com/blog/spikes.

Cohn, M. (2004). User Stories Applied: For Agile Software Development. Foreword by Kent Beck. Pearson Education, Inc.

Microsoft. (n.d.). User Stories & Product Backlog Items. Retrieved from https://microsoft.github.io/code-with-engineering-playbook/documentation/guidance/work-items/#user-stories-product-backlog-items.

Mountain Goat Software. (n.d.). User stories. Retrieved from https://www.mountaingoatsoftware.com/agile/user-stories

Mountain Goat Software. (n.d.). Non-functional requirements as user stories. Retrieved from https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories

Scrum Alliance. (n.d.). The anatomy of a user story. Retrieved from https://resources.scrumalliance.org/Article/anatomy-user-story

### PRODUCT BACKLOG ITEM

### TASK

Back to top