Have you ever had so much work in front of you that you didn’t know where to start? For me this situation became a reality when I went off to college. On day one I received six syllabuses that outlined all of the work I would need to accomplish in the next six months, if I wanted to pass my classes. Talk about a reality check. My dad gave me some invaluable advice at that time that has stuck with me throughout my career. His instructions were to read the syllabuses once to fully understand that mountain of work in front of me and gain the needed perspective. Then he said I should set them aside and only focus on the assignments for that week. Week by week I focused on the tasks in front of me and to my amazement, when I got to the end of the semester, I looked back and realized that I was standing on top of that mountain, having completed more work in six months than I had previously done in any given year. Little did I know at that time that my father was teaching me the main principle of project management.
As professional knowledge workers, most of us live in a world where the project or objective is defined, and then given to us as a monumental goal with very little detail on how to accomplish it. It is our job to quickly gain the needed perspective of the big picture, then break it down into chunks of work that can be consumed by our teams. In Agile Project Management, these smaller chunks of work are called User Stories. Let’s walk through what a User Story is, how it differs from tasks, and how to compose an amazing one that delivers results.
What is a User Story
A User Story is an Agile way to describe a chunk of work that poses a problem to solve but leaves the specifics up to the team. (Check out our blog on Object Driven Development to learn about the benefits of loosely defined objectives). The goal of a User Story is to quantify a small amount of work which can be completed in a short period of time with as few dependencies as possible. Let’s break that down
Small amount of work
The human brain is a lot like a computer and has bandwidth limitations just like any other signal processing mechinism. Our conscious mind can consume and process over 11 Million bits of information per second, but 10,999,900 of those bits are environmental variables from our 5 senses. This leaves us with mental processing power of between 50 & 120 bits per second to consume new information and process the potential opportunities and impacts of any given course of action. For reference, a bit is the smallest amount of information we know how to store or process and is essentially one true or false calculation.
Before we move on, can we stop and marvel at the fact that your brain can process 11 million bits of data a second? If you are familiar with computing measurements, that’s equivalent to 5 gigabytes an hour. Regardless of how amazing that is, only a small fraction of that is allocated to processing active information about things like projects at work. Out of the 5 gigabytes processed every hour, only 54 kilobytes can be allocated to work activities. This means that your brain has 99% less processing power than the very first computer named ENIAC from 1946. I digress. (Reference: https://www.britannica.com/science/information-theory/Physiology)
Based on our cognitive limitations, it is impossible for us to process all the potential impacts and action plans needed to pull off a large project all at once. Rather, our brain can only function when we break a large initiative down into smaller chunks and focus on developing game plans for each individual item. In agile these small chunks of work are called User Stories.
Short period of time
Parkinson’s law states that:
“Work expands so as to fill the time available for its completion”.
If this is true, then time constraints are a requirement for anyone who wants to complete a project. The key however is not to assign arbitrary time constraints without fully understanding the work that needs to be completed. This is the issue with establishing deadlines for large projects before they are started. Instead, Agile says that we should focus on small iterations of a few weeks and predict what can be accomplished during that time frame. This is done by identifying what User Stories can be accomplished in a given iteration upfront, then working as a team to accomplish those stories by the end of the iteration. By planning at the beginning of a sprint the team is able to gain valuable context and avoid the pitfalls of scope creep.
Few dependencies
Whenever something is broken down into its various parts, there are inevitable dependencies that must exist. When possible, a User Story should have limited dependencies on another User Story. This is not accomplished by removing dependencies, but rather through sequencing the work so that dependent work is done asynchronous instead of in paralell. The goal is to complete one User Story so that it can be marked as done, then to start a second User Story that enhances and builds on top of the first. In so doing we are able to build tremendously complex systems, one step (or Story) at a time.
User Story vs Task
So, what is the difference between a User Story and the traditional concept of a ‘task’? In traditional Waterfall Project Management, large efforts were broken down into tasks and charted out on a gantt chart, with each task being scheduled by date and dependent on the previous task. The trouble with this method is that tasks are predefined with the assumption that we can quantify and predict all the work that will be needed for a given project and then hand that work to any individual or group and receive the same output. This was born from a methodology known as Taylorisim in the early 1900 when assembly line factory work was the only way to deliver value to customers. Today however, our knowledge economy has created an entirely new breed of workers who are not interchangeable cogs in a machine, but instead smart, creative, problem solvers. In fact, in the book How google works these knowledge workers are labeled ‘Smart Creatives’.
Whereas tasks define a small set of work for a replaceable cog, a user story defines a small objective and then let’s the team or individual craft a unique solution in a given time. It is worth noting that many teams break User Stories down into their own tasks which is fine as long as the people breaking them down into tasks are the same people implementing them. Stay away from the anti pattern of Product Managers, or even tech leads breaking Stories into tasks and then assigning out work. This behavior is quintessential Waterfall.
Another common antipattern is that teams skip the User Story phase and jump directly from objective to task. This is fine when the objective is so small that it can be interchanged with a story and completed in less than one iteration or sprint. This is less than optimal however when the objective is of any significance in size or criticality. The better option is to let management, often the Product Owner, Product Manager, or Tech Lead, distill the objective into User Stories before the team is asked to start planning a solution. This allows the team to focus on a small chunk of work so they can focus and mentally process the tradeoffs and risks of various approaches.
The best way to think of this is that too much definition (a task) is detrimental to creativity and morale. Too little definition (an objective) is troublesome for cognitive capacity and leads to less optimal solutions. The sweet spot is in the middle and is called a User Story.
How to write a User Story
User stories should let the team know what a user is attempting to accomplish and why they need to accomplish it without defining how the problem should be solved. They generally follow this format:
As a USER I need to ACTION so I can REASON.
Here are a few examples:
- As a customer I need the ability to pay my bill online so that I can pay with my credit card.
- As a Teacher I need the ability to watch my students while they take their test so that I can better understand what is tripping them up and then I can adjust my lessons to prepare future students.
- As an administrator I need the ability to search for users with specific permissions so that I can figure out who needs to be contacted when a policy violation occurs.
As you can see, none of the above user stories told a team what they needed to build or how to build it. Instead the story created a base level of empathy for the users problem and then left the specifics up to the team. The team will then work together to solidify a solution that takes care of the problem. While they are doing so they will have the space to be innovative and possibly solve other user problems along the way.
If you are new to User Stories you should stick to this base formula until you get the hang of it. For more advanced users I would suggest a google search on the topic as there are dozens of articles proposing small modifications to the formula that help you get more granular without stepping over the line of defining the solution.
Rating User Stories
In Agile, the User Story is the level of work that should be estimated using the Planning Poker technique. (Take a look at our article, What is Planning Poker, for details.) In this technique teams sit around a physical or digital table and give a rating to each User Story. These ratings are relative to the other User Stories based on complexity. For example, if one story is twice as complex as another, the rating of the second should be close to double that of the first. There are a dozen scales by which to rate User Stories, from T-Shirts, to the Fibonacci Sequence, down to breeds of dogs. All of which have their place. (Take a look at our article on What is a Story Point for more details.) The main thing to remember is that we want to rate User Stories, not Objectives(too big) and not tasks(too small).
Some teams are asked by management to rate objective level or project level work, often with a T-shirt size, in order to give them a rough idea of expected time frame. There are numerous issues with this tactic, chief of which is that doing so generally means that you are operating in a project based environment which is often an Agile-ifyd way of operating in a Waterfall organization. I will save this topic for another day. But if this sounds like your organization, you should read the book Inspired by Marty Cagan.
On the other end of the spectrum you have teams attempting to rate tasks instead of User Stories. Oftentimes this leads to the team asking why they are using Story Points rather than just giving hour estimates. This is a valid criticism and the answer is that estimating in hours probably is best for task based rating.
User Stories on the other hand are the perfect pairing for story point estimations because a User Story is still abstract enough that it is impossible to nail down how much time it will take. Instead of spending the time to break a User Story down into tasks first, the idea is to rate the complexity of a Story relative to another story, then spend time detailing out the specific solution during the iteration or sprint.
Tracking User Stories
Almost every objective will have dozens of User Stories. The collection of these User Stories is called your Product or Objective Backlog. A backlog should be a living group of Stories that can be added to or removed from as new information is discovered. At the beginning of each agile iteration or sprint, the specific user stories the team has elected to tackle are moved into a Sprint Backlog. Ideally the Sprint Backlog does not change between the time the sprint starts and the time it ends. If you find yourself changing the Sprint Backlog often, you may want to consider shortening your sprint or iteration.
In order to keep your backlogs organized, I highly recommend utilizing a tool taylor made for it. There are several systems on the market today that enable User Story entry and tracking, many of which are free for small teams. The thing to look for is whether the selected tool has a Kanban Board view. If you are not able to get your hands on a tool you can utilize an excel or google docs in a pinch.
Summary
User Stories are powerful because they leverage the creativity and individual experiences of an entire team while creating a shared empathy for the root problem of the user. For User Stories to be effective, they should fit inside a sprint or iteration, be smaller than an objective and be less defined than a task.
Leave A Comment