Creating User Stories for Developers

User stories are a core part of Agile software development and involve all of the roles of a Scrum team in some way. Developers have a unique responsibility in creating user stories.

What is a User Story?

A user story is a function or feature of a product. It is the smallest piece of a product that describes a behavior. They are simple actions that an average user might need to do in order to use the software. User stories are completely functional. They do not explore technical or system requirements or details at all. Every user story is focused on giving the user the ability to do something. How the system accomplishes these tasks is handled after the user stories are finished.

What Does a User Story Include?

Good user stories follow a general format. “As a <user>, I want <goal> so that <reason>.” This format allows the scrum team to create a user story that is neither too general, nor too specific. With simple answers, the format should describe a unique function that deserves its own user story.

User stories should be independent and stand on their own. Each user story describes a bite-sized feature that is distinct from other system behaviors. One large feature can have several different user stories. Each part that can accomplish a goal should have its own user story to mark it distinct from other parts of the feature. Developers often have to write code for individual parts of a feature. It is better to have user stories for each of the individual pieces so that developers do not have to write an entire large feature in one sprint.

Unlike traditional development, user stories of Agile are negotiable. Most functional specifications in waterfall development are set in stone. Once an organization clears a spec, the product must match that spec to the letter. Changes often require several official documents and stepping through layers of red tape. With Scrum, user stories remain negotiable even until development is finished. If a user story is deemed unnecessary, it can be scrapped or reworked into something more useful. Some user stories may describe larger features that would be difficult for developers to complete in a single sprint. In these cases, the team may split the user story into multiple smaller user stories.

Only user stories that offer value should be created. Creating user stories give concrete goals and targets. Since user stories do not describe technical details, they can focus on product behavior. This allows teams to break features down and developers to work on them bit by bit. However, user stories that do not contribute to the overall worth of the product should be left out.

The best user stories are small and estimable. Features that are too large become vague and difficult to give work estimates on. By breaking these features down into smaller pieces, each individual piece is small enough to give an estimate of how many story points they will require. Where traditional development estimates tasks by hours, Agile gives story points. Story points do not indicate a definite amount of time but refer to general effort. User stories with more story points will require more effort than user stories with fewer story points. Assigning story points to a user story gives an indication of how large and complex that feature is. However, the user story should still be small enough that developers can finish it within a sprint.

User stories should be testable. Software development occasionally has a hard time determining whether something works. Changes such as adding new fields and other additions may not be directly testable. Several of these changes may be required for a new feature to work as intended. In these cases, the user story should refer to the functional changes that can be confirmed working. Several tasks in a user story can cover changes that will not affect functionality, but the user story itself should include some feature change that can be tested. A developers work may not always be testable, but these necessary changes should be grouped into a user story that is.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

What is this course?

This ‘Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)’ provides an in-depth understanding of the Agile Scrum Developer roles and responsibilities

You will explore the Agile Scrum project life-cycle, including how an Agile User Story is created, to how we know when it is ‘done’

This course is aimed at those with or without prior knowledge and experience of the Agile values and principles

During this course you will learn the tools needed to succeed as an Agile Scrum Developer

What will you learn?

You will gain an in-depth understanding of the Agile Scrum Developer roles and responsibilities, and you will be able to

  • Fully understand the role of the Agile Scrum Developer
  • Understand the roles involved in an Agile project
  • Create an effective Product Backlog
  • Effectively participate in Scrum Meetings such as the Daily Stand-up, Sprint Review and Retrospective
  • Identify the roles involves in the Scrum Team

What topics are covered within this course

You will cover the following topics during this course:

  1. An Introduction to Agile Project Management (Developer)
  2. The 12 Agile Principles (Developer)
  3. Introduction to Scrum (Developer)
  4. Scrum Project Roles (Developer)
  5. The Agile Project Life-cycle (Developer)
  6. Acceptance Criteria and the Prioritised Product Backlog (Developer)
  7. Initiating an Agile Project (Developer)
  8. Forming the Scrum Team (Developer)
  9. Epics and Personas (Developer)
  10. User Stories and Tasks (Developer)
  11. Implementation of Scrum (Developer)
  12. The Daily Scrum (Developer)
  13. The Product Backlog (Developer)
  14. Scrum Charts (Developer)
  15. Review and Retrospective (Developer)
  16. Validating a Sprint (Developer)
  17. Retrospective Sprint (Developer)
  18. Releasing the Product (Developer)
  19. The Communication Plan (Developer)
  20. Formal Business Sign-off (Developer)