You look at your to-do list and glance at the calendar, calculating the number of days you have before heading out on a holiday, and realize there is no way that you’ll be able to accomplish everything on your list unless you work around the clock. You know it’s time to prioritize, but it’s hard to even find a minute to think, let alone think critically and strategically about what the best use of your time is.
Three times in the last week, I had conversations with people about the Eisenhower Matrix as one of my go-to prioritization tools, but it occurred to me through these conversations that there is a significant piece often missing in this model that Scrum can help with.
The Eisenhower Matrix is a simple-to-use tool that helps prioritize tasks based on what is “important and urgent.” The tool suggests:
- If something is Urgent & Important: Do these things first.
- If something is Not Urgent & Important: it should be scheduled into your calendar.
- If something is Urgent but less important: delegate it!
- If something is not urgent and not important: Don’t do it at all.
As I was describing this simple, yet powerful tool I realized a critical, flawed assumption in this model. This model assumes that a person knows what is urgent and what is important. The questions we ask need to go past, “What is urgent and important?” to “What is urgent and important according to whom?”
Enter: User Stories.
In Scrum, a User Story articulates a general explanation of a feature written from the perspective of the end user. Its purpose is to show how the feature will provide value to the customer. A typical template for creating a User Story is, “Persona + Need + Purpose.” For example, if I have a list (i.e. backlog) that includes “fill X job postings,” then a User Story might be “fill X job postings so that the leader can get back to coaching and leading rather than filling in to meet product milestones.”
Understanding the perspectives of the people on the receiving ends of our tasks can go a long way to effective prioritization and, perhaps more importantly, to keeping the people we’re serving front and center.
Here are a few example questions to ask when you’re applying User Stories.
- What is the impact of filling the postings for the hiring manager, for the existing team, and for the candidates in our pipeline? If we understand the answers to this for the people involved, does it add to or take away from our backlog?
- What is the impact of drafting that policy for our organization, for managers, and for employees? Do we really understand the value of this? Do others in the organization?
- For the 'Z project' we need to complete, what is the impact to the people we serve if we do or don’t complete it?
Beyond helping to prioritize, my hope is that layering in a step of developing and considering User Stories will serve a greater purpose, which is to remind us why we do this work at all. Every task in our backlog hopefully represents impact, which is the only type of work worth doing.