Issues: bug, task, story and epic

Both scrum and Kanban project boards allow for different issue types. In many tools for project boards, developers can even choose their own issue types. This page covers the standard scrum issue types, and particularly the differences between stories, tasks and epics.

• Kanban and Scrum: What is the point?
• the key to agile: stories vs tasks
• issue size – how long is too long?
• Why stories are so important
• why ever view issues as tasks?
• Story Points
• issue types
  • bugs
  • tasks
  • stories
  • epics
• sprint building

Kanban and Scrum: What is the point?

Not as complex as many want you to believe

If you search for Kanban and Scrum on the net, the top results tend to be sponsored links pushing training, and products and presenting things as more complex than is necessary, so be aware of site professing things have to be a very specific way, when actually the key principles are quite simple.

An enhanced to-do list

The first basic principle is the principle of the to-do list.  Rather than drop what is being done at the time in order to deal with a new idea or new issue that arises and should not be ignored, add the new issue to the ‘to-do’ list or backlog, then finish the work in progress, knowing the new issue will not be forgotten.

The goal of the backlog is to eliminate having to many work in progress tasks, creating an overload of multi-tasking.  Juggle too many oranges at once and it is clear what will happen.  You could juggle the right number of oranges while leaving the rest on the table,  and periodically switch which oranges are in the mix so that all are being juggle, the switching loses time and can go wrong.

The backlog is like a table of waiting to be  juggled oranges that will not be forgotten, and will only join the ones being juggled once others have finished being juggled so there is capacity. Avoid the loss of time from switching tasks to deal with new issues the moment they arise.

A backlog goes beyond a simple to-do list, because:

• the ‘doers’ are not necessarily the same as those recording the issues
• there can be a significant passage of time between recording and issue and the issue being addressed
• the ‘to do’ list should allow for being agile and addressing the issue (or solving the problem) in a new way that may not have been obvious when the issue was recorded

These three points have significant impact that requires rethinking to-do lists.

Managed Workflow: Swim Lanes

There are three basic swim-lanes, the ‘to-do’, the ‘doing’ and the done.

The general principle is that issues move from left to right as they progress. Teams may add more columns reflecting more granularity of progress, and as an example, to clearly identify issues blocked by other issues.  There are alternative approaches for blocked issues and for most other concepts that can be addressed by additional lanes and  many teams find the three basic columns are the best.

Kanban vs Scrum: sprints

Various web sites will list many fine points of difference, but these are usually more between specific implementations of scrum and Kanban.  The basic difference is that scrum has sprints.  With sprints, a specific number of issues are moved from backlog to the project board with the goal of tackling these issues within a target timeframe.  Kanban is better suiting to dealing with work that arrives as a continuous flow and the backlog is simply and ordered ‘todo’ list.   With both Scrum and Kanban, that to-do list is impacted by the fact that the person recording the ‘to do’ may not be the same person as the person/team which will actually ‘do’ the ‘to do’.  Secondly, there is a need for agility so recording what to-do becomes less important than the reason something needs doing.  Kanban is usually implemented with limits to the size of one or more specific swim-lanes so that, for example, a maximum of five issues can be in the ‘doing‘/'in progress' swim-lane, blocking new issues from being started until the number already in-progress is reduced.

The Key to Agile: Stories vs Tasks

The concept of the story, and the difference from a task is central to agile development.

The question cans arise: “Is this a task or a story?” “What is the difference?”

The answer: Every issue has both a story and a task (or set of tasks)perpective. Story and task are as two sides of a coin.  The same thing seen from two different sides.

In simplistic terms, a task is what is to be done, and a story is why that task is to be done, or more specifically, what the benefit of the task being complete will be. There are many different issue types used by various teams: bugs, tasks, stories, new features, enhancements… etc.  However all of these have the same two sides: seen as an story (what is the problem to be solved) or seen as a task (what is the solution). Regardless of the label of an issue, everything can be described by the problem (story) or the solution (task).

task viewpoint:

• the solution
• to be done
• prescriptive

story viewpoint:

• the problem, the requirement
• the reason a task should be done
• the why do it?
• descriptive

Different Perspectives: Consider a non computing task, such as moving a filing cabinet from a corridor to another location because the filing cabinet restricts passage through the corridor and the corridor is being used as a fire exit.  The task is ‘move the filing cabinet’, the story is ‘the filing cabinet restricts the corridor which is being used as a fire exit’, or even ‘the corridor must be clear of obstructions as it is a fire exit’.  The temptation is to simply list what is to be done: the task.   Agile dictates, ‘no, list the story as an issue, with the task as a sub task’.  Why?  Because to be agile, the project needs to be open to more than one solution.  A key point is the issue goes to the backlog and will be tackled in the future when the best solution may have changed.  If it is months later, perhaps the corridor has already be widened? Perhaps the fire exit path has changed and no longer includes the corridor in question.  When it comes time deal with the issue, if it reads ‘move the filing cabinet’ the whole point of the move may no longer be apparent, or even valid.  Does the person with the task blindly follow the instructions at that time?

Bottom Line: Viewing issues from the story perspective is the key to agile.

If stories are so important, why ever view an issue as a task?

The three key differences between the simple ‘to-do’ list were noted as:

• the ‘doer’ is not necessarily the person adding the issue to the list
• to-do list are for the very immediate future while backlogs can include issues for longer times
• backlogs should allow for agility in how the issue is resolved

It is human nature to think of what we should do and treat the ‘why’ as ‘that goes without saying’. We do know why, and that the moment we are going to do something we have moved from ‘why’ to ‘how’.  Those 3 differences can certainly explain the ‘why’ no longer ‘going without saying’. We don’t have to explain to ourselves why, but we may need to explain to another person, especially when it is not even clear who that may be. Things that go without saying now, could need a memory jog in the future.  It is worth reviewing why in order to explore all possible solutions.

Keeping things as a task, does make sense if the none of those differences apply and

• it is definite the ‘doer’ will be the reporter
• the task will definitely be completed very soon
• there is no scope for considering alternative solutions or “being agile”

If all of those do apply, then recording an issue as a task makes sense.  But unlike a to-do list where no long term record is kept, it may still be relevant to look back in the future, so it is still recommended to record the ‘why’, even if less important in this case.

Just as having arrived at a ‘how’, even recording an issue as a story as some of the three original differences from a to-do list might apply, and it may be likely alternate ‘how’ options could be considered, the original ‘how’ should still be recorded with a story.
In the point, “the key to agile”, above.

Issue Size – How long is too long?

All issues to be scheduled in a sprint must first be have a time estimate to for completion that fits within the time allocated for the sprint.  If an issue is estimated to take longer than the maximum time that will fit in a sprint (see sprints, below) then perhaps consider the issue should be an epic, as Epics are not added to sprints.

Now imagine a sprint with one issue taking the entire sprint: not a great idea. Nothing could be marked as complete until the very end of the sprint, so no progress recorded. and zero feedback on how the sprint is progressing.   A further limitation is that it is very difficult to accurately estimate times beyond around two days.  A person can picture mentally how two days of time will actually be spent, but with a two week task, no one is picturing how each day of the of the two weeks will be spent.  The fact is, any estimate beyond around two days is just guesswork.  Over time, developers may get good at the guesswork, but within a sprint, it is best to drop the guess work and break down issues to sub-tasks such that no subtask will take more than two days of your time.

 

Story Points.

Estimating time for issues is problematic due to the fact that while project boards are like ‘to-do lists’,   the recorder of the issue, and ‘doer’ are not necessarily the same person/team, and time estimates depend on the view of the ‘doer’.

So issues should be placed in the backlog with an estimate of the size of the issue, rather than how long it will take.  So how do you record issue size?  Answer: Assign ‘Story points’ to each issue is the recognised best practice.

The requirement is that everyone working with the same project boards needs to have a common reference in order to measure issues in story points.   To do this, the first requirement is a scale, and the easiest to work with is a linear numeric scale, such that twice the complexity will double the number of story points.

The simplest possible story on the scale would be a ‘1’, double that complexity for a ‘2’ etc.  But what exactly does a ‘1’, a ‘2’ a ‘4’ or an ‘8’ look like in size?  The best way to cover this is to create a set of example stories.  Team members can add examples of stories then the team agree on scale number for the examples.  New issues can then be compared to the examples.  A review process could also have  recently tackled issues added as references:  “this was an 8, it involved these stages where the stages were (full explanation provided).  It needs at least 4 examples for the scale to be workable, but around 12 example (3 for each of 4 sizes) would be ideal.  New, better, examples could replace previous examples, once sufficient example are already documented.

Another discussion on story points can be found here.

The Issue Types

Tasks

A task is not really an issue type, but a way of describing an issue.  In fact, describing an issue as a task is the natural way to describe the issue.  A to-do list is naturally a list of tasks.  The reason for doing the task “goes without saying”.  Another occurrence of “what goes without saying” actually does need to be said, in part because what goes without saying today, no longer goes without saying several months later. The task needed doing is foremost in mind at the time of recording the issue, it can long be forgotten when the issue is to be addressed.  A different between ‘to do’ list and a backlog, is the possible long time delay between adding an issue and that issue being addressed from a backlog.

Another point is that it is exactly that which “goes without saying”, the very basics, that need to be questioned and examined when being agile.

All of these reasons are while describing an issue as a task is like looking at coin from one side. The task viewpoint is the best viewpoint for an individuals to-do list for the day, but the least important viewpoint for a backlog.  Adding an issue as a task should only happen when there is certainty the task will be addressed almost immediately.

For better results, always record the story viewpoint first, then add the task viewpoint. Or perhaps more realistically given how natural it is to first think of the task, first add the task as a sub-task to an empty story, then go back and add the story which at the time may feel so obvious it goes without saying.

Stories

The goal is to have stories for every issue, and record proposed solutions as sub-tasks for the story. This recording the story is examine the reason the task is to be done, and allow lateral thinking of alternative solutions, alternative tasks that could achieve the same goal.  The story is the essence of being agile.

Again, a ‘story’ is not really an issue type, but simply a way of thinking of an issue.  To address every issue there will be tasks to complete.

The art of good stories centres, on separating the solution and recording that in a sub task, and keeping the story about explaining what is the problem to be solved..

Bugs

A bug is actually an issue type.  The bug can be expressed in terms of the task to fix the bug, or preferably, the story of what the system fails to do correctly (the story).

Then main rule is that no attempt should be made to fix the bug before creating a unit test that fails due because of the bug.   With the failing test in place, and the test proven to fail while the bug is still present, it is relatively simple to then address the bug.  To record a bug, the obvious requirements are how to reproduce the bug, and what are the expected and actual behaviours.  Normally a bug will be added to either the current, or very next sprint, so what is recorded will be tackled soon, but it is still preferable to record the story and not just the task.

Features/Enhancements etc

These labels are again labels for a type of issue, each of which can again be described from task or story viewpoint. For agile development, the challenge is to become practiced in thinking in stories and ensuring the story is captured.

Epics

An epic is simply an issue to large to included in a single sprint, or with Kanban, tackled all at once. There are three strategies that I know for dealing with epics.

1. The Epic Sprint Series. If story spans several sprints, then why not devote a series of sprints to that story? Making the Epic into a series of sprints means no specific issue for the Epic is needed, just a title to a series of sprints, and the stories of these sprints build the Epic.
2. The Epic issue is an alternative for when the epic sprint series is of a very low priority, and there are many stories that will have higher priority, but it still matters to make a start on first stories of the epic.  In this rather specific situation, simply add the epic to the backlog as an issue type, and then design stories which together build the epic, but are each of a more workable size. Then add add each story to the backlog and tackle as with any other stories.
3. The Composite Epic Sprint Series.  The Epic story may have other Epic stories or regular stories should be completed in parallel, and should not be delayed until the Epic is completed as an Epic Sprint Series.  The solution in this case is to first redefine to epic as a composite that included the original epic, and also the stories that should be completed in parallel. Then complete the new composite epic as an Epic Sprint Series.

Sprint Building

Building a sprint requires selecting issues from the backlog, assigning them to teams or individuals and estimating how those story points will convert to time for the teams assigned.  As issues can arise during a sprint, and new complexities revealed to the original issues, a buffer is required between estimated time the issues will take and time available.  A sound rule is to allow for the sprint taking anywhere from the original estimate, through to double the original estimate.  So sprint with tasks originally estimated at 2 weeks should be allocated from 2-4 weeks.

But which issues to choose?

The real art to a well build sprint is to ensure cohesion, which the issues fitting well together, and combining to a concrete goal for the entire sprint.   The challenge of a concrete goal, is that most worthwhile goals require more than one sprint.  Putting the concrete goal as the target of a single sprint risks a sprint that loses its way and takes months.

The best solution is to have the concrete goal for a series of sprints.  Make the goals into what is effectively an epic, but do not create the epic as an issue, but as the goal of a series of sprints. Just as discussed in epics, as an epic sprint series.

Further reading:

Some notes on project plans.