From Scrum to Kanban

Customers who use Scrum to organize their teams have adopted Blossom to visualize their workflow and stay up to date about who’s doing what and why. Scrum and Kanban are iterative work methods which both have the objective to reduce waste. By setting the optimal amount of work a team can handle at one time the workflow gets smoother and work can be delivered continuously.

Differences between Scrum and Kanban

	Scrum	Kanban
Roles	* Dedicated pre-defined roles * The Scrum Master dictates timelines * The Product Owner defines goals and objectives	* No pre-defined roles * Cross-functional team helping themselves out if somebody is overwhelmed * Self-organized and autonomous
Due Dates & Delivery Timelines	* Work gets organized in Sprints which define what gets delivered in a specific time-box. * Time-boxes are usually set between 1-4 weeks in which work must be completed.	* Products or features are delivered continuously * On-demand prioritization and delivery
Prioritization	* Larger batches of work or features are defined for the upcoming sprint.	* Team members “pull” new tasks once the previous task is complete and as soon as there’s time ready for new work (“Pull System”).
Changes	* Changes tend to be avoided since it would affect the future release estimations and timeline and requires to recalculate estimations and in the worst case to a halt in the process.	* Allows/welcomes for changes and for continuous improvement anytime during a project.
Measuring Performance	* Measures productivity by Sprint Velocity which measures the work done by the team per sprint, tracked over many sprints. * The upcoming sprint relies on the success of the sprint before it.	* Measures productivity by the amount of time it takes to complete a feature or chunk of work from inception to delivery, also called “Cycle Time”.
Principles & Attributes	* More prescriptive on when and how work gets completed * Defined processes and roles * A specific pre-defined amount of work is broken up into time-boxed Sprints * 1-4 week Sprints * Scrum Master prioritizes work and what gets built next	* Customize Kanban to fit the processes and work methods your team already has in place * Self-organized and collective prioritization based on higher level goals * Small and frequent release cycles * Work gets pulled rather than pushed (“Pull System”) * Allows changes and improvements to take effect immediately and anytime * Continuously reflect on the past and improve the process on evolutionary fashion

The Production Workflow

Set up your production board
The first step in configuring Blossom is to set up your stages on the production board. To reduce complexity we recommend trying to keep your stages at a minimum. For a Scrum like process, we recommend setting up four workflow stages User Experience > Current Sprint > Quality Assurance or Review > Party or Done.

Set up an idea board
For “ideas”, “cards to be implemented”, “sprint backlog” or “product backlog” we’d recommend keeping those on a separate board and create a new card or copy the card over to your production board (as seen above) as soon as the idea is ready to be implemented. Peace of mind and full focus on the things that are currently being implemented. An idea board could look like this:

Defining Work & Planning
At your weekly team meeting you determine features to be implemented and add them as cards into the first stage (in our example “User Experience”) on the production board.

Current Sprint
During the week, the team focuses on executing the cards on the production board and cards flow through the process from left to right. If cards could not be finished in a week the card simply remains in the stage as long as it takes to get finished.

As soon as a card is ready to be “pulled” into the upcoming stage “Quality Assurance” you can add the visual indicator stamp. Team members responsible for the review then pull new cards as soon as there’s time ready for them.

We recommend to regard a feature card as something called ‘minimum marketable feature’. This usually is something in between a user story and an epic.

Checklists within a card are often used to break a card down into concrete steps like user-stories or other forms of specifying a requirement (whether it is implementation or research related).

Sizing & Estimation
Going forward we want to add functionality for sizing complexity of a card using smart tags (e.g. story points). Some of our customers and we ourselves at Blossom use a framework called T-Shirt sizing (XS, S, M, L) to add an estimated size of a card. Depending on the size of a chore type card or smaller tasks, they usually get the prefix XS or S (e.g. XS: Login Bug). Depending on your preference you could alternatively use the Fibonacci Series 1, 2, 3, 5, 8, 13 (e.g. [2] Login Feature).

Quality Assurance
Cards that are ready to be reviewed get pulled into the Quality Assurance stage of your production board.

You can add additional quality assurance steps during the overall workflow by describing what each stage is in a stage policy. Stage policies set quality standards and minimum requirements for cards to be in a specific column. This clarifies what it means for a card to be in a stage. Considerations or requirements that should be met at a certain stage of the process can be defined as well in a stage’s policy. Find out how to set them up here.

Party – The last stage on the production board
Cards completed which passed all quality assurance and acceptance testing can be moved to the last stage of the production board. ?

Learn more
Make sure to check out our Blossom Product Management Resources and our Product Love Collection on Medium where we cover Scrum as well. Find out how to do continuous delivery with our step by step guide to a continuous delivery workflow.