Sprint demos are done at the end of each sprint to the clients. This helps to identify the issues and collect feedback from the clients. I have a question about implementing the demo feedback. Should we consider demo feedback as a bug, story, or task? Usually, we receive feedback from clients to improve the UI and workflows. Please share your opinion on this.
2
-
1Sounds like a fairly subjective question - quoting from help center, "You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page."– MCWCommented Feb 20, 2019 at 17:56
-
Is the demo the first time your client sees the work that is being done? "feedback to improve the workflow" seems like the kind of thing you should be getting during the sprint, not at the end.– ErikCommented Feb 20, 2019 at 18:35
Add a comment
|
1 Answer
tl;dr; There is no "right" answer. Whatever works for your team and client.
Probably Not a Bug
Sprint feedback is rarely a bug. While there is no strict definition, a bug, or defect, is a term usually reserved for when an application does something that everyone knew it shouldn't (or vice versa). So unless demonstrating the feature happened to turn up a bug by coincidence, you won't usually get bugs out of the review.
Other Types of Backlog Items
Keep in mind that a story is just one type of backlog item and it is meant to express a need or interest from a user. In that regard, it may be well suited to encapsulate the feedback from the review because it can capture the who, what, and why of the feedback. For example, if you show a graph and someone says it is hard to read because they are color-blind, you could write a user story like:
As a color-blind user, I would like to be able to view the graph in a color palette that is color-blind-safe so that it is not strenuous to read the reports.
This is also really useful because many times feedback comes with proposed solutions. For example, a red-green color blind person may suggest colors that work for them without considering other types of color blindness. A user story is a great way to make sure you capture the feedback without having to pass judgement or make a commitment on the proposed solution.
On the other hand, I was in a review once where an international feature didn't appropriately localize the date order. Now, you could call this a bug if you wanted to, but the team didn't because no one had discussed it before. It was basically a new uncovered need. You could format this as a user story (As a German user, I want the date... ) but it doesn't really add much value, so they didn't. They just created a generic backlog item (some tools call these Tasks, not to be confused with sub-tasks) that read "Localize Date Format, see notes for details" and it worked fine for both the team and the client.
