Working with designers and developers, we have found that we all do our best when we have clear goals and a strong understanding of the task at hand. Over the last couple of years, we have made the move to manage our work within Asana and as of recently, we have moved our work focused conversations away from Slack and into Asana. Since making this move, we have found a lot of opportunity when it comes to drafting Asana tickets. Our solution: better user stories.
User stories are the list of functions that a product does, whether it is a mobile app or a website. A user story answers the following questions: Who? What? End Result?
Who: Who does the end result of this task impact? A user, admin, designer, developer?
What: What action does the user need to do in order to accomplish their goal?
End Result: What is the user’s end goal?
For our projects, we conduct Sprint Planning and write our user stories together. This helps us have a clear understanding of what the project scope is for the sprint and will prevent us from adding additional out of scope features throughout the project. We also found it critical to estimate each task so we know how much we can handle for the week. There are several ways of estimating tasks. Here are a few of the most popular, which have been suggested within the agile methodologies.
- Relative Sizing. This is when we estimate the level of effort to stories that are relative to each other. This can be done using story points or Affinity Estimating. Affinity Estimating means that stories are broken down in buckets from small to large.
- Ideal Time. How long would the task take if the creator/implementer was not disrupted and had everything they needed? We have seen Ideal Time work best for estimating design tasks as many of our designers spend a lot of time meeting with clients. Estimate as if you had no interruptions.
- Wideband Delphi Technique. Gather opinions of experts and produce an accurate unbiased estimate.
Another major driver of success when using user stories is to make sure stories are not dependent on each other. Find ways to make each story independent so that individuals’ success is not based on someone else's actions. Keep each user story simple, write all stories in simple text so everyone can understand the meaning. User stories should have enough detail for others to be able to go into the task and determine if it is completed or testable. Finally, each task should have acceptance criteria because this will help us understand what is allowed and determined as a success. If the acceptance criteria within a task is met, we can call the task complete.
How does your team use user stories? We’d love to hear from you!