The way we describe tasks to be done influence the way they will be processed. If the person who will work on them know the purpose of the action. If he know under which clear expectations he will be evaluated. If he has all the necessary information to start working without losing time to get extra info. Will determine his efficiency, motivation and autonomy in his daily work.
So agile methods propose a framework to describe tasks to be done and evaluate their completion status.
Work in short iterations
Agile methodologies and especially scrum are all requiring that you organize your work in short iterations typically 2 weeks.
These 2 weeks iterations are called ‘sprint‘ in scrum methodology (by far the more popular of agile methodologies).
We will talk from now only with scrum methodology terms as it is the more popular and you will find them in many agile applications.
But what does this mean for task to be done ? The direct consequences is that tasks must be small enough to fit under 2 weeks, ideally just in one to be able to finish several in on Sprint.
But in agile project management tasks are not the only concept to define things to be done.
User stories, tasks and epics
Scrum introduced two new levels to define actions to be done : agile epics and users stories. Tasks still exist but as a sub-level of a user story.
Agile epics are just a group of user stories so the main new concept to discover is user stories.
So what are user stories ? How it is different from tasks ?
What is an agile user story
User stories are named that way because the description of the task is written from the view point of the client or final user.
You tell a story to your user with his own words, focusing on his priority, his main concerns, needs, pain points.
The intent here is to remove the technical jargon so that it is no more a brake for client, final user to evaluate if the action is adecate or not.
Also it force agile team to think and recall the objectives to give the project users a benefits sometimes called business value…
So user stories are small piece of values that can be delivered and evaluated by the client and finalized in one Sprint, typically 2 weeks.
What should a user story contain
A typical scrum user story should contain the following content :
- A title : make it short and descriptive : it is the main text that people will use to recall what was this US (user story) about
- A short explanation of the task from the view point of the final user with the structure
As a (user type that talk) I would like to have a (the thing to do) to be able to (added value) this phrase will help everybody technical or not technical to understand the subject and always recall the final objectives that can be blurred otherwise by too technical discussion
- A complete description of what needs to be done
- A list of acceptance criteria this could be unusual for you but you always had in minds precise expectations that your coworker may not have. Also the person that will work may do too much in a direction that is not useful and this loose precious time. So better clarify the expectations that will be used to evaluate if the user stories will be marked as done or not.
- Screenshots, illustrations an image is often more efficient that a long text to understand immediately what the US is about so it is very important to always include some visual content
- Related files be it Excel files, text document drawing document online files and ressources. It is better to have them at hand or a link to them. In order to be very clear about what are the good files, where they are…
What is the difference between tasks, epics and user stories
User stories are a unit of added value from the, client perspective
Tasks are more fine grain technical actions to be done. They can be inside a user story and sometimes be called sub-tasks. Or independent as sometimes purely technical tasks need to be done that do not need to be explain Ed from the user perspective.
Epics are groups of topics generally organized by thematics. It is a way to track completion in a more global view across sprints.
Why user stories need to be small
User stories need to be small to fit inside a sprint! Yes but why?
They need to be small and independent from other tasks if possible.
Two small tasks marked as done are more motivating for the person that will work on them.
The product owner and stakeholders could give then their feedback early, help them articulate with the next projects tasks.
Make user stories not depend on other helps prevent situation where we can be blocked because one part only is blocked. And the agile Sprint rules are clear. no unfinished user stories will be counted as done!
We will talk about that definition of done in a later post. In the meantime, why don’t you sign up for the Bricks app which we’ll launching soon!