How To Give Constructive Feedback on User Stories

As a participant in an agile project I want to know how to give constructive feedback on User Stories so the team can continuously improve.

In many software development projects, the adoption of agile development principles has had a great start, but may be struggling when it comes to implementation. I’ve seen examples of that in the way features and requirements are broken down into programming tasks and further on into testing, deployment, and maintenance tasks. The best way to tie all these tasks together is to describe the end result as a User Story and reference the related tasks to that. That way, whoever does the related task will always have the expected end-result in mind and can without effort see what other tasks are planned for that story. As with many other things, starting can be difficult and may need a lot of collaboration so the best way to get started is to know how to give constructive feedback on User Stories.

  • What is a user story?
  • How can the team prevent feature- or scope-creep using acceptance criteria?
  • How can scenarios put the acceptance criteria back into the context of the user story to make it testable?
  • Who should give and take advice about writing user stories?
  • Who should decide on the level of quality for a story?
  • What makes feedback constructive?

The goal with this article is to describe one way to assess the quality of user stories and provide constructive feedback on how to improve them.

What is a user story?

A user story is a simple way to describe a feature, its target audience, and its merits in a single sentence. It is basically requirement specification in agile projects.

The simplest form is the strongest as the following:

  • As an [role],
  • I can [feature]
  • so that [reason] (optional)

For example:

  • As an [administrator],
  • I can [edit posts by any member]
  • so that [the post can meet the quality standard of the forum]

Check out this great article about writing user stories.

Set boundaries with acceptance criteria

The acceptance criteria are rules that define the user story. Without them, user stories are open-ended and ultimately suffering from feature creeps. Consider the following examples:

  • The post can only be changed by the author or an administrator.
  • Members can only use the products they have payed for.
  • The video will start when the page is loaded and the window has focus.

The acceptance criteria are clear, specific, and unambiguous.

This article has some nice practical examples of acceptance criteria.

Add context with scenarios

Scenarios are used to give context to the acceptance criteria of the user story. Some acceptance criteria can occur in multiple scenarios. The scenarios make the user stories testable.

Consider this simple form for using scenarios:

  • Scenario [#]
  • Given [context]
  • When [event]
  • Then [outcome]

Applying the example from the user story:

  • Scenario [1]
  • Given [an administrator is logged in]
  • and [has loaded another user’s post]
  • When [clicking the edit button]
  • Then [the content of the post is editable in a text field]

Adding a variant of the scenario:

  • Scenario [2]
  • Given [a user is logged in]
  • and [has loaded a post]
  • and [is the author of the post]
  • When [clicking the edit button]
  • Then [the content of the post is editable in a text field]

The team should agree on the criteria of a good user story. If a story does not meet the criteria, simply ask yourself and each other: “what is missing”, raise your concern and your preliminary answer with the team – even if your answer is so simple that you are almost embarrassed to say it out loud.

This article has a great example of Acceptance Criteria vs. Scenarios involving baby pets :)

How To Give Constructive feedback on User Stories

The team and yourself may not agree to the solution, but that’s okay.

The key is that you share your concern in a concise way and show the way to a solution by communicating a possible solution to the team.

Maybe your answer is really good and it solves the issue with the user story. Great, now move on. Your solution may also be really bad. Also great!, if you are part of a team that you trust and you all know that you simply suggested the solution in lack of a perfect solution to start a collaborative discussion on how to solve the problem. There are many degrees of perfect, especially in the context of a project where time, cost and quality are the determining factors. The perfect solution could be the dirty hack that moves the project forward.

The idea here is that the culture in your team has to support even the worst suggestions because they can start deep conversations that may lead to genius solutions.

Trust yourself and your team, lead the way to the solution, and know that your solution may not be the best.

Leave a comment: describe pitfalls when creating user stories and how to give constructive feedback in agile teams.