Recently, I wrote a short piece on Scrumban agile processes entitled “Moving To A Batch Size of One”. This piece was responded to by some (thanks David!) with concerns about planning and scheduling, or the lack of apparent planning and scheduling in this ScrumBan system which I will briefly address now. In Scrumban, we eliminate iteration planning and instead implement a system of continuous rolling-wave planning. Let’s say that a team has four simultaneous workstreams: large new features, small new features, large maintenance activities, and finally smaller maintenance activities. As new requests arrive into the team on an almost daily basis, which is common in many organizations, the team does a quick assessment and sizing of the request and figures out which workstream the request goes into. Our product owner will prioritize the activities for the team as usual so they know exactly what needs to be done next. With some simple metrics, we can soon track velocity around the four workstreams so that the team will know that on average:
- It takes 3 days to deliver a small maintenance request +/- 1 day.
- It takes 10 days to deliver a larger maintenance request +/- 2 days.
- It takes 5 days to deliver a small new feature +/- 2 days.
- It takes 15 days to deliver a large new feature +/- 3 days.
Through these simple metrics and a continuous planning system, the team can make pretty accurate commitments and never have to stop the production line for iteration planning. With continuous flow, we do not have to figure out exactly how much work will fit within an iteration because there are no iterations; just a continuous flow of delivery to customers. This may not be an appropriate system for all forms of development, but for some shops with a constant flow of new requests and ever changing priorities, this may be a potential solution.
