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.
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.
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 ?
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.
A typical scrum user story should contain the following content :
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.
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.