Feature image “Proto-Persona” by visual.ch (CC BY-SA 2.0)
When a product owner or product manager helps create user stories with the development team, does the development team walk away feeling empathy for the customer? Can the development team and business benefit if the team ‘feels’ for the customer? Most businesses are pushing their development teams to produce all the time, from project to project, so developers eventually get used to this pressure and find their own behavioral niche within the organization. So why would a team suddenly begin doing more work in less time than any project before?
At a previous company, we had the advantage of being able to know the names of our customers and potential customers. This didn’t always happen but when the development team knew a customer’s name it was magical. During the daily stand-ups, the development team talked about the next bit of work they’d tackle but they’d also talked about the customer, “Is that what Bill (not the real name) wants us to do?” Management also talked in terms of the customer when speaking to developers. The development team knew their stuff and were top developers but they looked at the work with an eye equally on their customer’s wants and needs. The team spoke the customer’s name so it was clear they knew exactly who they were working for. The team’s productivity shot way up and they even worked weekends to get the right product into “Bill’s” hands sooner. This was a dream team for the business and would be the envy of most companies doing Agile. Or Waterfall.
Now that’s a nice, feel good story about a development team’s awareness of their customer but this is probably the exception. E-commerce businesses flourish these days with thousand upon thousands of customers so it would be difficult if not impossible to get a development team rallying around a single customer. The next best thing is a persona representing a customer, a customer segment, or a user profile. I first learned about personas from Alan Cooper in his book, “The Inmates Are Running the Asylum”. At the time we might have missed the mark sometimes because our personas were very detailed in things that nowadays would be considered unnecessary and less helpful in aiding product decisions. However, personas can help development teams feel a closeness to their customers and be more empathetic towards their customer’s pain.
What I generally notice is companies have personas but they’re often used only in Marketing. The idea is to get these personas out to everyone involved in product development and steering the full product team’s thinking towards personas as real people. I was at a great presentation by Atlassian product manager Sherif Mansour who spoke at Agile Australia a couple of years ago on the topic, “Do Agile Right – Lessons Learned From an Atlassian Product Manager“. This easy to listen to video touches a bit on using personas and journey lines. Atlassian uses personas as the backbone of their product development. If you’d like more information on creating personas, see the end of this article.
User stories by Mike Cohn
Connextra is credited with the most popular user story format, “As a <blank> I want <blank> so that <blank>“. This is a simple yet elegant way to capture “who”, “What”, and “Why” for a software requirement. But it’s Mike Cohn and his book, “User Stories Applied“, that really made user stories come alive in the Agile community. Mike Cohn does suggest that the ‘why’ is optional but I think for teams early in their Agile journey, this will be very beneficial as it helps new Agile teams understand the customers’ problems better.
A good user story can provide an innovative and imaginative development team all the necessary information to begin their task of talking with stakeholders and the product manager in order to figure out how they’ll do the work. The goal of the user story is to provoke conversations to get more details rather than writing a specification.
So does this happen and if it does, how often? My experience shows this in fact rarely happens. Yes we write user stories using the format, “As a <blank> I want <blank> so that <blank>”, but we’re really following a cargo cult software engineering ritual without really understanding the purpose of the user story. This is exactly where personalizing the user story can reap great benefits.
Personas in user stories
A lot of user stories I see look like this:
“As a user I need to see an error count so I can track whether the number of errors exceeds my reporting threshold.”
This story was constructed for the “user”. Unfortunately “user” is such a general term doesn’t tell us who the story is for; is the story for an 8-year old or 80-year old grandmother? Is the story for men or women? It’s going to be hard for someone to read the story and be empathetic toward the “user”. There’s no human connection to this story so no one should expect much in the way of human feeling toward implementing the story. The development team is just as likely create a display item that shows a simple error count because that’s the easiest and fastest way but is it the best way or is it what the customer really wants? What’s missing is the personalizing of the story which can be expressed in the form of a persona. By personalizing the user story, the question the developer asks is, “is this what ‘Grandma’ wants?” instead of, “does this meet the acceptance criteria?”. If the whole product team, (finance, marketing, sales, support, development, and product management), are behind helping Grandma out, it’s just that much more likely to happen.
Personas and visibility
Now someone reading this is saying, “but we said who the user was at the grooming session” and that’s great but now you have a story that only a small handful of people knowing who the story is for. This shows a certain complacency within the agile team and not being transparent to the business. By avoiding tying the story to a specific business concern in the form of persona, other parts of the business are in the dark as to the real value provided to the business by delivering this story. How easy would it have been to put in persona “grandma” instead of “user”? The Product Owner and Development team owe the business this insight and should always be aware of what they’re communicating to the business. If the agile team is looking for autonomy and empowerment, what better way to earn this than by being open and showing they are striking at the heart of business concerns.
The real advantage of personas will come from the development team as they create solutions in quick and caring way. Even if the development team only increases value delivered by a couple of percentage points, the product manager, the business, and the customer win. This can happen if the development team’s interest, excitement and commitment can be inspired by using personas. Atlassian treats their personas as people and the company talks about their personas as real people. This is not too far from the experience I spoke of earlier in this piece where the team talked about their customer.
There are as many styles of personas as there are customers. If you link a user story to a specific persona and that persona maps to a business or customer segment, then it will be easy for the business leaders to quickly see the potential value the team is planning to deliver. It also gives the development team a chance to relate their work to the goals of customers represented by personas.
I am assuming most people reading this are familiar with creating personas but for those less familiar, here’s a site to get you started with personas. There’s also help from Roman Pichler who, in his article “From Personas to User Stories“, provides a template for developing personas. An example of Roman’s persona template is shown below. Roman suggests that personas and their goals begin their appearance in the larger, epic, user stories and flow all the way to sprint ready stories. This will help focus the team on solving problems for a semi-living customer and it will also make user testing easier because the goals of that customer are defined in the persona.