Defining specifications in an agile environment is often done by defining user stories in the form of As a "persona" I want "function" because I "reason". In most situations this could work well. Especially when the functionality is used by a clear persona using the function. Screen oriented functionality can be described in this way. There is a clear understanding:
So what to do with the functionality that is needed to fill in the user stories then? That don't have a clear persona, but is a feature that is needed by the system? You could see these as the foundation for the system to be able to fill in the user stories. Well, you could use a feature definition: "action" the "result" "by for of to" "object". The point here is that I think forcing every specification into a user story is not working and make specifications more vague.
Back to the user story. The part I want to emphasize in this blog is the "reason" part. This is revered to as the business driver of the user story. Part of defining specifications is being constantly aware why the story is created. The reason why is often to create some function to help the persona in some way. I.e. adding value for that persona. Fulfill a wish or resolving a pain or maybe automate a job the persona does. But that sounds familiar. These are the important subjects on the persona. So knowing your customer and your customer customers is important to define a good why on a user story!
The image above shows the relationship between user stories and personas. When you are focussed on delivering value for the user, then a user story should be a implementation of a wish, a pain killer or a automation of an user job. Or a combination of them of course. Then you will have a good why for the user story.
Next thing to consider is that you probably made a lot of assumptions along the way. With a certain user story you assume you fulfill in a wish, resolve a pain or automate a job. Taken together that the wish you defined on the persona a real wish? Or do you assume that's your personas wish? So therefore a lot of assumptions. What if you could somehow validate those assumption?
Of course in some situations, you can define prototypes, do interviews and other activities to validate those assumptions. But there is probably already a good source of finding proof. Think of your customer's support data, sales interviews, support desk data, etc. There is a lot of proof hidden in that data. What if we could use that in an automated way? Then we will have an easy and cheap way to have a first form of justification to spend money on prototyping and organizing user interviews or even start building? Maybe we will find new wishes, pains and jobs our customers do we didn't even think of. So utilizing that data in our agile way of working and let it help us making the right choices on prioritizing our development efforts would be great. More on this topic in a later blog.
If you also have an opinion on this subject, please comment or contact me. I would like to get in touch to have a chat.
Agile architect, coach, scrum master and developer with a lot of years of experience in different combination roles. Passionate in making ideas a reality. Good ideas and a good open environment with the right people make the impossible, possible. Creativity, the right technology and an open team spirit are perfect to get it done in this time of innovation.