Estimations in Agile development – Epics, User Stories and Tasks

Agile, scrum, Kanban and Lean are no longer “new” methods for software development. There are hundreds of articles, books and courses about them. However, most of them include introduction material that mainly focuses on the basics. If you actually start using one of these methodologies you’ll quickly ask yourself with a missing – how are you supposed to estimate your work?
If you search the web you will see that there is not much data about estimations, simply because it is HARD. It is very hard to estimate correctly. Jeff bezos used to say “If you are planning for more than twenty minutes ahead in this kind of environment, you are wasting your time”. We cannot predict the future, but we can maximize our chances in getting as close as possible to it.
After reading several agile books (e.g. Agile Estimating and Planning by Mike Cohn), scrum courses and 6 years of practicing Scrum and Kanban in various projects I’ll try to add that missing piece called estimations in Agile development.
This is the first of 4 posts in the “Agile Estimations” series.

1. Epics, User Stories and Tasks (you are here)
2. Estimating User Stories with Story Points
3. Sprint Planning Methods: Capacity vs. Velocity vs. Feature
4. Improving Estimations using Burndown, Burnup and Actual time metrics

This series is not an introduction to Scrum. Before you keep reading, you should be familiar with the agile manifesto and Scrum in general. There is no “right” way to do Agile. You should change it so that it fits your needs. However, it is very important to understand the root principles and evolve from them.
Making the series practical
In order for this entire series to be practical and not just theoretical we’ll apply the content on a Youtube like application that I’m building right now. It should allow users to upload and watch videos. It should allow users to edit their videos details and rate others videos. It should have search, tags and filters (top seen, recently added and more). It also should recommend different users videos that matches their interests.
Let’s start
Before we jump to the different approaches regarding estimations let’s first understand what is it that we need to estimate. A project’s specification evolves with time. It starts with large and unknown features requests and eventually transforms to some tiny and technical tasks. In this post we’ll understand how this transformation does happen and why.
It is not just User Stories
Everybody knows that in Scrum and most of the other agile methodologies you must have a board and some sticky notes on it.

*Maybe your board is not a physical board but it is still a board. With notes.
What are those notes? They are the actual work that is currently being done. The actual tasks that the team is working on in order to accomplish some user stories. User stories represent the user’s need. A feature that should be added to the application that will gain the user value. The tasks are the technical representation of that need.
A user story represents a feature. However sometimes that feature doesn’t stand on its own or it is part of some bigger feature or a business concept that incorporates several features. That is called an Epic.
Epic
An epic is the biggest representation of a feature. In order to deliver an epic to the user we must divide the epic to smaller pieces – user stories.
*In the Agile books epic is not divided directly to user stories it first divides to something that is called “Themes” and only they are divided to “User Stories”. However in the last 6 years I have never seen any team that uses Themes therefore we’ll not use them either.
In our application we have three epics:

1. Allow users to find, play and comment on videos
2. Allow users to upload and edit content
3. Recommend videos to users based on their interests

This is our current product backlog. A backlog is basically a list of features that represents all the user’s needs and wishes. The backlog has two main principles that we should always apply:
1. The backlog must always be prioritized from high to low according to the user’s needs.
2. Every backlog item must have a “DoD” – Definition of Done that defines when the feature is actually complete. Sometimes it is called “Acceptance criteria”. It doesn’t replace the full description of the feature or its design. It is only a single sentence (maybe a couple) that describes how the feature will behave in the end.
Our backlog is already prioritized so let’s add DoD to the epics.



*there are many agile management tools out there. You don’t have to use them, a physical board and sticky notes can be enough. However, when working on big project a dedicated virtual tool might be really useful. I personally recommend on Visual Studio Team Services.
Remember that the epics should not include any technical or implementation details. They should only describe the business value. A more detailed description will be found inside the epic’s user stories.
By prioritizing the backlog we know what is the most important feature that the user needs, hence it will be developed first. After we’ll finish it we’ll move to the next one in the list. This way we always deliver the user what he wants the most.
I think that this is one of the best concepts in Agile development that is so different from the traditional ones. This way we can deliver small and valuable features to the user and receive feedback along the way.
Breaking Epics into User Stories
So the first epic is “Allow users to find and play videos”. In order to get a better understanding of what it really means we should divide it to smaller pieces – user stories. Every user story should match the following template: “As X I need/want Y to do/so that Z”. As a logged in user I want to update the details of my videos so that they be correct.
It is extremely helpful when a user story has at least X and Y defined since it clearly expresses the main role of the feature (As a logged in user) and by so the relevant business stakeholders of this feature.
Will we fail if we won’t name our user stories like that? Of course not.
Do all the user stories need X Y and Z defined? Definitely not. However doing so makes you truly understand the scope and value of the feature.
Epic: Allow users to find, play and comment on videos




Few things to note:

• The DoD adds meaningful information for the implementation of the feature.
• The use of user and logged in user for separating the action of an anonymous user and a logged in one.
• The priorities of the user stories determine what the most important feature to the user is and which one is the least.
• Every user story gives actual value to the user and brings us closer to the epic’s DoD.

Now we can split the top user story to its technical parts – the tasks.
User story: As a user I want to play videos from a list of videos




The complete backlog:

So now after we are familiar with all the product backlog items it is time to give them estimations.
But how do we estimate?
What estimation units should we use?
What are story points?
Do we have the same estimation units to all the backlog items?
 
All the answers and much more are in the next post.
 
Estimations in Agile development – Epics, User Stories and Tasks (you are here)
Estimations in Agile development – Estimating User Stories with Story Points (go here)
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics