(This post contains affiliate links. Read my full disclosure.)
Regular readers will know that I’m not at all experienced in formal
Today I’m partnering with Eylean to give you an overview of three
Agile Methods: The Basics
Scrum is a way of managing the work within defined timescales called sprints. These generally last between 1 and 4 weeks and you work through your task list in that time. It’s relatively formal in that respect as that deadlines are tightly respected.
I think of the Kanban method as a way to visually manage To-Do lists. There are few formal constraints and you adapt your Kanban board (more on that later) to reflect your workflow as you wish. There are no hard deadlines but you can work towards a release or a larger goal.
Scrumban is a blend of the two, as you’d expect. You’ve got the idea of a continuous flow of work within longer planning cycles that tie into your release dates.
Who Makes Up The
Scrum, as the most formal of these three methods, has formal roles: Product Owner and Scrum Master (plus other cross-functional people who make up the ‘team’).
The Product Owner is kind of like the waterfall Project Sponsor. She sets the vision and priorities. The main difference I think is that sponsors are rarely part of the team day-to-day. Product Owners are right in there with everyone else.
The Scrum Master is the person whose role is similar to that of a project manager: someone who leads and manages the Scrum process.
There aren’t formal roles prescribed for Kanban and Scrumban so you can use whatever you want, or no formal roles at all. Kanban team members tend to have specialist skills but Scrumban teams could be made up of specialists and generalists.
Read More: 5 Structures for Agile Teams
How Work is Planned
Scrum teams take their requirements from the product backlog. The Agile Alliance defines the backlog as:
“a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release.”
During planning you prioritize the work for each sprint. There’s a ton of negotiation at this point about making sure that the right tasks are being done in this planning cycle.
If a big task can’t get done within the sprint time frame then it will be split up into smaller chunks because the sprint dates absolutely have to be respected.
Scrum teams have awesome
Kanban is far more relaxed. The team can add work when their task lists are empty or at any other point – as they don’t work with sprints there are no fixed points where they have to come together to plan.
As Kanban team members tend to have specialisms, they can take their next task whenever they’ve finished their current workload and there isn’t the requirement to wait until the next formal planning cycle to get more work allocated.
Scrumban teams do their planning when they run out of work to do, or in
How Tasks Are Displayed: Kanban Boards And More
All three approaches use visual display boards (which today are more likely to be on your computer than on your office wall, but you could still go old school). These show the tasks and what stage they are in the process of getting done.
I’m actually a bit in love with Kanban boards. I think the idea of moving work visually between columns is great and a really simple communication tool for teams.
Here’s an example of an Eylean Kanban board:
I struggle with them because I am not a visual person. I’m wordy. But if I worked in a team where we were using
Kanban boards and Scrumban boards sit there and are used over and over again. It’s a continuous flow of work, so the tasks hop on one side of the board and make their way over to the other side where they drop off.
Scrum task boards are wiped and reset every time a new sprint starts to reflect the requirements planned for this sprint.
Here’s an example of a Scrum board. They don’t look that different at first glance but the backlog tasks are described as user stories and there are some other subtle differences.
How Tasks Are Allocated
The more traditional role of the project manager sees tasks being allocated or assigned to team members. In reality, that’s done based on discussion and taking into account team members’ skills, experience, and interests.
Scrum teams get to choose upfront so they each know what their responsibilities are during the spring. Kanban and Scrumban teams choose as they go.
Having not lived this process myself I can only assume that it’s actually similar to the discussions I have with my team. I can’t imagine that core business requirements are not delivered because no one fancies working on them for the next month.
Both Kanban and Scrumban have a ‘work in progress’ limit. For example, I can’t do more than one book review for this blog at a time, so my workload would only show one at a time.
How Progress Is Measured
The burndown chart is the key way to measure progress in Scrum. Burndown charts have always struck me as complicated and I expect they are if you have to create them manually. Fortunately, software tools make it a lot easier as it’s all automated for you.
Burndown charts show you how much work you have ‘burned down’ i.e. completed. They illustrate how much work is still to do (the blue line in the picture below) and what the idea progress would be (the dotted line – waterfall people, think actual work vs planned work on your Gantt chart).
They also display other performance metrics such as the concept of ‘value’ (the green line in the picture below) which should go up as the team completes more work.
Progress in the Kanban method is measured in two ways:
- Cumulative flow: A graph that shows total items in progress
- Cycle time: A measurement that shows how much time it takes to complete one task.
Scrumban uses cycle time too. Here’s what a cycle time chart looks like:
The limitation for this that I would like to explore further is what happens when your tasks are not supposed to take the same amount of time? Average cycle time then becomes meaningless. A deeper analysis of
Agile Method is Best For You?
So, which of Scrum, Kanban and Scrum Kanban should you be choosing?
The answer, as it so often in project management, is ‘it depends’.
Scrum has advantages for big projects that need to stay on top of the requirements and deliver regularly. The Scrum Alliance says that the approach is particularly beneficial for complex projects.
The Kanban method is probably less suited to a project environment and more appropriate for operational teams dealing with a steady stream of work.
Scrumban gives you the benefits of timeboxing work into sprints and releases with the flexibility of being able to add new work and cope with business-as-usual type work too. That would work well for smaller teams who manage project work alongside keeping the business operational, for example in a start-up situation.
While I’ve learned a lot during the writing of this article, and I hope I’ve explained some of the main differences between the approaches, this isn’t enough for you to make a decision about what is right for your team. There is also the hybrid approach mixing
If you’re thinking about adopting
Further Reading: Agile Project Management for Dummies by Mark C. Layton. This is my ‘go-to’ book for understanding
I’d like to thank the team at Eylean for sponsoring this article and helping improve my knowledge about