User Stories

SET THE STAGE

Who are the players?

Every winning team knows which players to have on the field and what talent you need on the ready. To successfully deploy this play you will need the following roster:

Meeting Facilitator: Likely this is you! But you don’t have to do it alone, ask a friend (think of it like a football team that has a coach for different parts of the team). Skills needed:

• Keep the team focused on the goal!
• Foster a positive and creative space for all
• Organized and prepared to run play

 Product Manager: A product manager is a professional role that is responsible for the development of products for an organization, known as the practice of product management. Product managers own the business strategy behind a product, specify its functional requirements, and generally manages the launch of features. Skills needed:

• Ability to balance business and user needs
• Attention to detail
• Curiosity to explore new ideas
• Ability to deliver factual data in-time
• Empathy for customers
• Ability to build strong relationships with other teams
• Understanding of necessary data structures
• Informed about the technical implications of the platforms being used
• Ability to tailor communications to different stakeholders

 Product/System/Business Unit Owners: These are decision makers. They can make the call on what changes will happen or authorize a strategy. Skills needed:

• Change agent. Supportive and enthusiastic about improvements.
• Supportive of the team and SMEs!
• Committed and engaged in the product.

 Subject Matter Experts (SMEs): A SME (pronounced S-Mee) is critical for this play. They will help drive the team to a shared understanding of what is needed to win. Skills needed:

• Specific domain knowledge, narrow and deep rather than broad and shallow.
• Communication and team collaboration. They must be able to share with others the knowledge they have on a particular subject. 

Get the field ready!

Schedule the meeting in advance. Don’t wait until the last minute to schedule the meeting. You want people to be excited about it but not so last minute that they have no time to prepare.

Include an agenda. Set expectations – this will help keep your meeting on track. Include schedule and any prep work needed. Also let them know if it is okay to invite others or not. Remember that if you have to many people in the meeting, it will be difficult to facilitate brainstorming sessions without breaking out into smaller groups.

Prep the room. Arrive early and get ready. If it is in a physical room, get whiteboards ready, enough chairs for everyone, water and snacks are always a hit! If virtually, a central location for notes, brainstorms and follow-up items. Test connectivity in the meeting room and make sure there is enough seats for all participants.

CORE ACTIVITIES

THE BACKSTORY TO USER STORIES

“Storytelling is the most powerful way to put ideas into the world today.” – Robert McKee

The art of user stories is about expressing the requirements from the perspective of the end user. It is associated with Agile, but isn’t an actual artifact of agile methodology, rather an adopted format that is easily understood by development teams, who often are using Scrum and other Agile frameworks.

So why do we love it so much? Because anyone can write a great user story! Most often by product owners or product managers, but because it is in plain language, free of technical jargon or detail, anyone can write a user story for consideration. They only need a good understanding of the user-persona problem that they are hoping to solve.

Vintage user stories typically went like this: 

They were written on an index card (remember those?) that could then be tacked to a whiteboard to be prioritized. The development team would review them and assign an estimate on level of effort to complete, then they would get shuffled around until they had a well groomed board.

Today we have come a long way from the days of index cards and rolling whiteboards of work charts. Most teams use electronic tools to create user stories and digital boards to organize for the team.

THE ART OF WRITING GREAT USER STORIES

You could still use the classic user story format and create good stories. But if you want to create great user stories you will need to go beyond the basics. This may take some practice but once you get the hang of it, you will be able to produce great stories with no problem at all.

1. Understand the user. Who is the recipient of this deliverable? What are their needs and why do they want this? If you can’t easily answer these questions you may need to spend time to define user personas with the team. You need to discover and study the real users of your product — capture their profiles, points of view, expectations, and the associated ‘pain points.’ Create a direct communication channel with your users to really understand your the real users of the product. Establish a set of key users — ideally in the form of personas — before you start compiling user stories. 
2. Think as a user. Easier said than done. If you are a product manager it may be difficult to see it from the perspective of someone who doesn’t know all there is to know about the product. Ask your Grandma to be a user, or a young person who hasn’t used your product – the feedback you will get will allow you to really see it from the user’s point of view. The product owner and the entire team need to think from a user’s point of view and understand the underlying needs and the expected value.
3. Thing big! A good practice is to think big and let ‘crazy’ user stories enter the backlog. Don’t limit yourself with constraints of time, cost or feasibility. To often this turns into solutioning and will box in the development team on delivering value. The administrative overhead of maintaining an extended product backlog is small; the value deriving from it — in terms of product clarity, vision, and opportunities — is massive.
4. Use epics. If you aren’t familiar with epics, get familiar. They are a great tool for containing a larger story that will be broken down into smaller stories. This is a great big picture tool. Epics are like large tote containers that can contain smaller bins of great ideas. In more traditional terms these might be milestones or themes, but they should still serve a common goal.
5. Prioritize ideas. During grooming just move low value ideas to the bottom of the backlog rather than deleting. If it is of no value and high cost, be very careful to add it to the backlog at all, as this will just create noise that can distract the team from identifying high value ideas. Need help? Use our Prioritizing Work play to identify high value, low cost ideas. 
6. Setup for success, not just acceptance. As a product manager, you need more than a confirmation that ‘it works as it should’ or ‘according to the specs.’
   You need metrics that are also linked to direct user feedback, capturing how happy and engaged your real users are. Success is about mid/long-term impact and value created for real users of your product. 

Phew! Okay so now you are ready to really create some great user stories. You thoroughly understand your user, their needs and what is success. Try this format:

“As a [persona],
I want to [do something]
so that I can [realize a reward]”

Get the team together and create some great user stories! But you aren’t done yet – ah man!

You still need specs

Having a prioritized set of well-defined user stories is great, but it’s only the beginning. The team needs to analyze the stories — from a technical point of view — and create the necessary technical artifacts.

Ideally, stories are mapped to specific documentation that provides all the technical details needed from a software engineering perspective. They provide the entry points for detailed technical specification documents and other detailed artifacts.

USER STORIES AND THE TEAM

User stories are your anchor for working together on what you’re going to build and how you’ll know if it’s working. Team members come together to confirm a shared understanding of the user story. Use INVEST (a pneumonic device created by Agile consultant Bill Wake) as a checklist to determine if a user story is ready.

• I – Independent. User stories shouldn’t overlap and should be able to be implemented separately.
• N – Negotiable. User stories should be flexible and have space for negotiation.
• V – Valuable. User stories should add value for the user.
• E – Estimable. User stories should provide enough information so that people can estimate how much time it will take to implement.
• S – Small. User stories should be small in scope and able to be implemented in one sprint.
• T – Testable. User stories should be testable. If you can’t write a test for it, then the user story probably isn’t clear enough.

Where do user stories live?
User stories live wherever you want them to live. What’s most important is that your user stories are visible and accessible to everyone, whether that’s JIRA, Google Drive, or Post-its/index cards on a wall. You can’t experience the full collaborative experience that user stories facilitate if no one can find them.

Making your user stories and epics searchable and easily categorized through the use of meta tags and the like will make it even easier for people on various teams to take advantage of this collaborative tool. And if you’re going to go the analog route, consider having an electronic back-up. This will help you track the evolution of your user stories and will be a useful reference even after the product is released.

In conclusion, user stories give you a bird’s eye view of all the various pieces required to build a product. This makes it easier for you and your team to come up with effective solutions for user problems, resulting in a smooth user experience.

Recommended Resource

Want more info on how to write great user stories? Check out this article on alexandercowan.com

 TEAM HUDDLE

Time to run the Team Huddle play. Ask the team the following questions and then take a vote. Keep follow-up questions to a minimum and capture any issues raised as an offline follow-up (and be sure to follow-up).

Understand the play?

The play was understood and I asked any questions in time!

I’m not sure I understand and I have some questions …

I did not understand the play or my part in it.

Did you get in the game?

Yes, I made my moves and was in the right place at the right time!

I’m not sure I understand what I was supposed to do …

I kept the bench warm and watched from the sidelines.

Ready for what’s next?

Yes, I know the game plan and ready to win!

I’m not sure what’s next or if I am involved …

No clue what’s next and would rather sit it out.

NEXT STEPS

Phew! The hard part is done! You might be tempted to go further and prioritize the backlog – but don’t! Instead congratulate the team on a very successful first go at user story writing and give some time for them to keep practicing!

Schedule the next meeting where the team will regroup and give feedback on the system set up. Set a regularly reoccurring meeting cadence so that the team stays engaged and is front of mind.  

Publish your notes in a central repository that the team has access to immediately. Even better if it is someplace that the team can add comments or collaborate on. Keep the creative chat going! 

IT’S A WRAP

You did it! Now just a few follow-up items:

• Reflect on the play. Ask yourself how it went? What could have gone better, what could have gone worse? In sports this is watching the game again to see any plays that could have been better. Update your playbook. Build feedback loops that help you see what’s working; what’s not; and how to continue to develop the playbook by learning, adapting and iterating constantly as situations change and new challenges arise.
• Contribute to the community of Playbook.Ninja. Sign-up for an account and receive updates on when new plays are added and help others by commenting on the plays with what worked or your experience.

Thank you for being a Playbook.Ninja