Product Owner: “Please code this feature”.
Developer: “I can’t code this, until I receive a better spec”.
PO: “Just go ahead, I want your input to this as well”
Dev: “Alright”
— Developer codes it like he believes is the best, and show it to the Product Owner —
PO: “Why wasn’t _this_ included?”
Dev: “It wasn’t a part of the spec”
PO: “Well, I think it is kind of obvious, and I wanted your input as well”
Even though this is a simplified example, I’m sure many can relate to both the Product Owner and the developer walking away from this conversation pretty frustrated. The Product Owner for not getting what he wanted, and the developer for being blamed for not doing his job good enough.
Trying adding more details to the specification doesn’t seem to do any good. This forces the Product owner to describe the technical solution, which is not often the core competence of a Product Owner – and shouldn’t be! It can lead to developers hesitating to contribute to the technical solution, and just following orders. Not exactly what you’re looking for when you want to deliver high quality software.
So what is missing in this case? Seen from a leadership perspective, the missing link is a way to communicate, which promote the Product Owner to focus on user needs, and bringing the technical expertise from the team into play.
User Stories is a tool for doing exactly this. However, it can be a challenge convincing people who are not used to User Stories, that describing a feature in one line, will add more details for developers, than trying to specify all details in some kind of a handover document. To read more about how User Stories can help providing all necessary details, you can refer to Ron Jeffries Three C’s of a User story.
The one-line user story specifies, WHO should be able to do WHAT, and WHY? Even though the Who, What and How are equally important for the user story, I tend to say that the Why is the most important. This is simply because, the Who and What often comes natural when describing features. The Why part is often forgotten, but this is where the value lies. It is litteraly the value for the user that is described here, but it also defines the context of the feature for the developers, the motivation for coding this feature.
So when implenting the use of User Stories, my advice would be to focus on the “why” part, as this will quickly show value for developers and Product Owner, making the acceptance of the format easier – if you should meet resistance.
Ok, we have got the one-line user story now, then what? In my experience the dialogue got going by itself, simply by writing the userstory. Product owner are describing the feature from a user perspective, and developers begin to ask question, to get the technical understanding in place. Conclusion of the dicsussion, should of course be noted down. I have had good experiences in writing acceptance Criteria in the format: “Verify that….”. Acceptance criteria defines the scope of the feature. It is easy for the Product Owner to describe what will actually be developed. It is easy for the developers to know what to develop. And it is easy for testers to know, what to test.
After implementing User Stories, developers have expressed to me:
- It is more motivating to work on a task, when you know the context.
- As a tester it is very easy for me to know what to test.
- I thought I was done with the feature, but the acceptance criteria made me realise i was missing something.
- It is way easier to commit to features, now that they are well described.
Agile Reflections 