The purpose of this document is to outline the Scrumban process for use in Mobelux projects. This is a living document, and subject to change.
Some teams may choose to implement a Scrumban(Hybrid Scrum and Kanban) process on development projects. This is a good fit for new products and other projects that could have lots of changes or team availability inconsistencies.
The main features of a Scrumban process are the following:
- Daily team meeting to encourage communication
- Limit work in progress(WIP) to encourage focus
- On-demand planning to encourage agility
- Triage at end of project to encourage completion
Teams will do a daily "standup" meeting to keep communication flowing about the project. This will normally be done in person at the office, but if the team is out of the office(ex: Fridays) it can make sense to use a video chat room. The web team has an Appear.in Room that can be used.
Iterations should be kept small and flexible. Teams should aim to keep iterations small enough that project changes will not cause major disruption. Iterations do not need to be on a set schedule, because planning happens as needed.
A difference from Scrum planning and sprints is that planning meetings only happen when they are needed. This is normally triggered by the backlog getting down to a certain number of items left.
Less time should be spent on task estimates than in a Scrum process. It will be sufficient to estimate the average time that a group of tasks will take instead of time for specific tasks. This will still allow us to adapt estimations and adjust process accordingly.
Tasks should be prioritized primarily by the product owner. Within work in progress teams should prioritize tasks that are blocking others to keep work flowing. Higher priority tasks should be sorted to the top of lists.
In general, tasks should be made large enough that they take a couple of hours to complete on average. This allows focus on a feature set instead of doing many 15 minute tasks and constantly managing cards. There will be tasks that are smaller and larger, but being able to estimate against and average is useful.
Tasks can be written as user stories if it makes sense for the project. They should be tasked out based on the components involved in the card.
As much as possible tasks should be assigned as late as possible, with the ideal being that developers pull tasks from the available tasks. Late binding of tasks allows the most flexibility of the team and changes to the project.
The Current column should be limited in size to prevent multitasking. If a task is blocked it should be put back in the Backlog, marked with a label as Blocked, and be available for someone else to work on. Current size limit should be team size + 1. This allows for minimal multitasking for high priority bug fixes, but prevents the whole team from working like that.
When a project approached completion(5-15% left) the team should finalize what features will be included in the release and push the rest to the Someday column. Bug fixes and final features will be the priority to finish up a release.
Periodically as needed a process evaluation meeting should happen to discuss how things are working and suggest improvements. This meeting should be triggered when needed.
The primary measure of development will be cycle time, which is how long it takes an average size task to get fully developed.
Fitting this process into our existing Trello usage patterns is not hard. Columns can be used as follows:
- Someday - Tasks that are not specced out enough to be worked on yet.
- Backlog - Tasks that are specced out and ready to be worked on.
- Current - Tasks currently being worked on, limit to team size + 1
- Completed - Tasks that are in QA
- Accepted - Tasks that are fully deployed
We will make labels for the following:
- High Priority/Critical - Should be done before regular priority tasks
- Blocked - Needs something before it can be done. Should go to the Backlog and the person it depends on should be tagged in a comment.
- Bug - Cards that got added outside of the normal process, normally from QA