Scrum vs Kanban: Managing Change Effectively

Imagine a common scenario - A new Agile team is following Scrum and is using 2-week Sprints. They start their Sprint on Monday morning and pick about six stories every sprint. Fast forward to day 4 (Thu)... all six stories are in progress, and testing has started on two of the stories. Now, PO approaches the team with an important change request - a new story or a significant change to an existing story.

The SCRUM Way

Here are some of the common ways the A Scrum Dev Team may respond:

1. "Yes, we will accept change" - Good chances the management culture in the organization favours a "Never say NO to Business" policy.
2. "No, we can't accept change" - Team follows a strict "NO Change to Sprint scope" policy, thanks to an empowered Scrum Master (or Agile Coach) who believes it has been so written in Scrum Guide.
3. "Let's see!" - Team practices a more mature approach of "Negotiation" between PO and the Dev Team.

The negotiation process may roughly take the following path:

i. The first question Team poses to the PO is "Can it wait until the next sprint?"

The question forces PO to do some mental math... today is Thu, so 7 days more before this sprint finishes, and then they start working on this request which will take 10 days more. So, total of 17 days before the change can be ready for Demo or deployment.

ii. If PO responds with "Yes, it can wait", there are no issues at all.

iii. If PO says "NO, it can't until the next Sprint", the team may ask another tough question - "If this change is important, what would you like to take out from the Sprint scope?"

• If the PO is not willing to take anything out, it may lead to a conflict situation that will possibly escalate - leading to some roughness in PO-Team relationship.
• If the PO is more compromising and is willing to move a story out of Sprint scope, the team may still feel bad that the time/effort spent on that story is being wasted.

For more details on how a mature Scrum team handles changes during Sprint, please see my previous article "Should we allow Changes within Sprint?"

The Kanban Way

Now, let's see how a Kanban team will deal with a similar change situation.

Consider the same team with similar velocity/throughput of three stories per week. The focus in Kanban Method is to enable a continuous flow of value to customer at a predictable pace, without compromising quality. Like most new Kanban teams, let's assume the team replenishes their Ready Queue once a week (Monday mornings) and the WIP limit for Ready Queue is 5. The team pulls a story from Ready Queue into development whenever they have capacity to do so. In other words, a pull mechanism is in place.

Now, what happens if the Request Manager(PO) approaches the team with a new story on Thu?

With a throughput of about three items per week, there are good chances the team may have pulled two or three items from the Ready Queue. When PO takes the new story to the team, the guiding principle is to look at the capacity available in the Ready Queue, which in this case is 2-3. With empty space (capacity) in Ready Queue, the new story is most welcome. The only additional effort required is to plan a short meeting meeting between Request Manager (PO) and the team to understand the new story in enough detail - unless it has already been discussed before (say Backlog Grooming meeting in a Scrumban implementation).

With a Ready Queue that holds committed yet untouched items, it is rarely the question of whether to accept change or not. The more important question in Kanban (Method) is how to treat the change. Below are four common options:

1. (Default) Move the new story to the bottom of the Ready Queue - it will be picked up in order.
2. Higher Priority: If the new item has higher priority among all items in the Ready Queue, move it to the top, so it is picked next when the dev team has capacity available.
3. Fixed Date: If there is an urgency to complete the new item before a certain date, the team may consider the option of elevating it to "Fixed Date" class of service, which means the team will not only pick it on priority but also finish it with priority. As an example, think of a new feature the customer wants to go on their site during the upcoming Special Sale.
4. Expedite: If the new item is so urgent that almost nothing else matters, the team could consider it as an "Expedite" item where the team will concentrate all their energies in finishing the new item as fast as possible. As an example, think of a production defect that has been determined to cause serious security threat to your banking customer.

Thanks for taking time to read this post. Look forward to read your thoughts and experience in how your Scrum/Kanban team deals with requirement changes.

[This article was first posted on LinkedIn. Please find the original post here.]