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
- Kanban and Scrum: What is the point?
- the key to agile: stories vs tasks
- why ever view issues as tasks?
- issue size – how long is too long?
- Story Points
- issue types
- 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 that of the to-do list. Rather than drop what is being done at the time, to deal with a new idea or 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 that are all being juggled thing to be done, and to 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
The three points have significant impact that requires rethinking to-do lists.
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 ‘
'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).
- the solution
- to be done
- the problem, the requirement
- the reason a task should be done
- the why do it?
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.
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.
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 a set of example. Team members can add example to scale list, and with a review process that has 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
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.
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..
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.
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.
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.
- 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.
- 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.
- 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.
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.