When you empower your software development team to make decisions about the details — and in case you hadn’t noticed, that’s one of the core principles of agile practices – you must also supply them with an arsenal of tools that help them make the right decisions. Understanding who will use the software they’re building is one such tool.
But it’s not good enough to just say, “we’re adding this feature so that people can draw on their photos.”
One engineer might post a lot to sites like Reddit and Quora, so she thinks “redact license plates and faces. Got it!”
Another is a visual artist and thinks, “Select areas and add colors, blend, maybe some stroke filters…”
A third is all about Instagram and thinks, “funny filters and stickers! Let’s find some libraries to offer.”
Certainly by the time the item has gone through refinement you’ve set this team on course for the right kind of drawing. But why not save time and establish the intended use more clearly from the start by telling them what kind of user the feature is for?
A persona is an aggregated biography of a certain type of user of your software. Each persona should be based on real people in the role that they represent, which can be derived from market data about the slice of the population that has that job title or role. Personal details like age, gender, home life, marital status, hobbies, and geographical location should all be derived from market demographic data. Even more importantly software usage details must match the role that the persona represents.
Does all of that sound more like marketing than software requirements? It should. Personas are a standard marketing device. And it also should because you’ve most likely got to sell your software to that same market. If you aren’t building your software for your market, why are you building it?
So let’s write a user story for that photo drawing requirement:
“As Raul the frequent social media poster, I want to obscure parts of my photos so I can post them on public forums without revealing any personal information that I don’t have the right to and earn ‘likes’ or ‘karma.’”
You just eliminated a half hour of debate over the scope of the item. Redacting license plates it is!
Giving the persona a name and a biography puts real people in the minds of the team members. You know your team is maturing when you hear them referring to your most common personas by name.
Identifying the persona that each requirement is for helps you keep your product focused. If you can’t figure out which persona wants the requirement, perhaps you shouldn’t be doing it at all. If you have requirements for a legion of personas, you’re probably spreading yourself too thin. Most of your requirements should be for a single, primary persona. Try to satisfy more than one and you’ll end up satisfying none.
At Streamline we have a sizeable inventory of personas because we’re actively developing four software products (which have sub-products with different user types). The personas are a common resource – some of them use more than one of our products. A great example is Dorothea the user administrator. She’s a busy lady, handing user accounts for all of our products!
Dorothea is one of our “secondary” personas – others include technical support analysts, implementation engineers, and report writers. These are not the main roles that we build software for, but they do interact with our software in very specific use cases.
Roles we do not have personas for are the Product Owner, the Scrum Master, the chief architect, and other engineering management type roles. Why not? Well, are we selling our software to those people? No.
I once had an inexperienced business analyst argue that the scrum team’s work was going to be judged by the product owner, so the user stories should be written from the product owner’s perspective. Yikes! The product owner is just a conduit for other stakeholders’ requirements. This attitude smelled of the command-and-control culture that our organization was trying to overcome at the time (and largely has). Watch out for this kind of perturbation of the intent of agile practices — they can slip in when you aren’t looking!
We recently gathered data for requirements by primary and secondary persona for each of our products. One of them has been doing as much for secondary personas as primary personas, and one has done more for secondary personas! When we drilled deeper we found out why: we’re commercializing one, and fixing data infrastructure for the other. But if we couldn’t lay our finger on these reasons, we’d need to take a good long look at those backlogs as related to our company goals. (You’ll note that I’ve used that redaction feature to obscure the product names.)
How would this metric look for your products?