Conversation Patterns: Don’t Confuse a Need with a Feature

This article is part of my work on Conversation Patterns for Software Professionals

I have used an Inverted User Story presented in User Story Template Revisited during some workshops with teams and I want to add a tip.

How to recognize you discovered the right benefit or problem to be solved. Well, you can’t. You should stay aware of a conversation flow and test a timeliness of stakeholder needs. So the core need driving a user story doesn’t escape your notice. Try to implement the Heart beat design pattern in your mind 🙂

But you should distinguish between „need” and „feature”. A Stakeholder often confuse these two. For example:

As a Logged user I want to generate salary report so that I will know who is a VIP

Without a wider context it’s difficult to validate the story. But, „I will know who is a VIP” is probably a feature, not a need. It’s because it points a system feature, but not a stakeholder benefit or problem to be solved.

I want to score under this is my supposition and I would fire up my Heart beat pattern asking a stakeholder about a need details.

In general you may use following heuristics to recognise stakeholder need:

  • Benefits you discover, mostly fits to the template: I want to achieve…[benefit]
  • Problems to be solved you discover, mostly fits to the templates: I want to avoid….[problem to be solved]