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.

How to deliver test statuses at a daily scrum

As an agile tester, I want to share the status of the project’s testing tasks with my team, so we can solve any issues and impediments before they become bottle necks.

This article will give you an idea of how to deliver test statuses at a daily scrum. The test related work in agile teams seems to revolve around user stories and their acceptance criteria. This will naturally also be the centre of the discussions in daily standup meetings (or a scrum as it is often called).

Here are some of the basic question that I will address in this article:

  • What is the basic agenda of a stand-up meeting?
  • Which testing activities should an agile tester be planning for an iteration?
  • What testing constraints should an agile tester be prepared to meet?
  • What obstacles impacting testing should an agile tester be prepared to address?
  • What to consider when communicating in cross-functional teams
  • The beauty of Failing Fast and sharing it based on trust and shared responsibility

How To Deliver Test Statuses at Daily Scrums so Everyone can Understand It

One of the rules of the scrum is that it is time-boxed, so you don’t get to chit-chat – you have to be concise. Another scrum rule is that each and all members deliver a status including obstacles and next steps within the time-box. It is pretty much like a turn-based game where each player go through the turn’s phases:

  1. what was your tasks since last scrum
  2. what are your tasks until next scrum
  3. what may prevent you from accomplishing them

A case: You’ve been working with a coder on a user story for an email opt-in form on a website:

“As a non-subscriber,
I can submit my email on a landing page,
so I can receive updates through the email marketing channel”

You’ve established the acceptance criteria and the need to do an exploratory test that include an integration to an email marketing provider, but you don’t have the customer’s credentials for the service so you can setup a test environment for the integration. You’ve already collaborated with the coder on the tests and there is a stub that can receive the email.

This is how you’d give your team the status update:

“Yesterday, Coder Bob an I tested the story for the email opt-in form on the landing page with a stub.
Next step is to test that the integration to the email marketing provider actually works.
However, I need the credentials to the email marketing service so I can setup an email-list that can catch the output from the form”

To that, the product owner would naturally answer:

“Sure, I’ll get it for you after the meeting”

There: three breaths of air and everyone on the team knows exactly what you did, what you’re about to, and what holds you back from doing it. You even got a solution to your problem in less than 30 seconds. (I should add that the example story is pretty short and there would be more of the same kind in your status update. Problems of this size could also be solved outside the standup meeting, but for the sake of the example and me not being able to come up with a real problem, please play along here).

In the case, you clearly state your task since last stand-up meeting, your next step, and the obstacle you’re facing. A team member have the solution to your problem and it is clear what has to be done and who will take the next step.

However, what if not all team members know what you’re talking about, even if you speak no riddles?

In agile teams all members have different skill sets, which is good. It is therefore important, not only to be concise but to also provide enough information about an obstacle so everyone can understand it and potentially help you clear the obstacle.

It is a two-way street: if you find yourself in a scrum not understanding a fellow team member’s problems it is your job to ask for just enough details to understand the problem. Don’t babble on or encourage the speaker to do so. Simply raise your hand and ask concisely. To riff on the example, you might not know what an email-list is in the context of email marketing providers. Ask: “What is an email-list”. Everyone at the scrum will know the context of the question and know that you ask because you might have a great solution to the problem if you know more about it.

Fear of inadequacy might withhold some people from asking that “dumb” question. Fear of inadequacy and “dumb” questions simply does not exist in pure collaborative work. You’re already a team member, so you’ve probably been chosen for a unique skill set that fill the gaps of other team members – perhaps even your ability to ask questions in a way that reveal unforeseen issues, in which case it is your duty to practise that skill until success.

  • Be concise.
  • State what you did,
  • what you’re about to,
  • and what may hold you back.
  • If in doubt, ask
  • and ask again.

What is your take on how to deliver test statuses at a daily scrum? Do you share similar experiences or is there a side to it that you think is important? Leave a comment and let me know.