When does the team discuss requirements when using Kanban?

Question

I have been reading a bit about Kanban and I am slightly confused on the topic of Requirements.

In my current project we use Scrum. At the beginning of a Sprint, we have a session where the BA does a walkthrough of the Story and describes it as best she can. We then take the story, review it, discuss it and prepare a questions for the BA for the next Sprint planning session. On the next session, the BA answers all the questions and the session finishes with us having understood the requirements (well most of the time).

The next step is that we then produce a technical design and develop the solution/story.

With Kanban, everything I read suggests there is no Sprint Planning in Kanban. My question is at what point (in Kanban) do the techies and the business folk sit down together to discuss the requirement for the story? Doesn't the Product Manager or BA provide a walkthrough of the Story in Kanban?

With Scrum, the BA is usually available throughout the Sprint to support the development and I assume it is the same with Kanban. It is not clear for me though how with Kanban, the techies understand the Story if there is no sprint planning.

Answer 1

You're right that Kanban doesn't have the concept of Sprints or Sprint Planning like Scrum does. That's because it's a leaner methodology. More things are done just-in-time.

It's up to you to decide how to schedule planning activities, but I would recommend doing them as close to the start of work as possible. This is most effective when there are representatives of all of the major stakeholders embedded on the team (the same also makes Scrum more effective).

I think that this diagram, based around Disciplined Agile Delivery, gives a good pictorial representation of a lean software process:

The events of the Daily Standup and Sprint Planning are captured across the Coordination Meeting and Replenishment Modeling Session. Coordination Meeting is more like a Daily Standup from Scrum and a Replenishment Modeling Session is more like Backlog Refinement and Sprint Planning. However, it's OK to bring in some requirements discussion into the Coordination Meeting if that works for your team.

Like most things in a lean process, this happen just-in-time. There are no timeboxes and events don't happen on a particular cadence like they do in Scrum. You do the work when it adds the value for the team and stakeholders.

Which you can compare to a pictorial representation of a process based on Scrum modeled in the context of Disciplined Agile Delivery:

Instead of constraining yourself to 2-4 week Sprints with planning at the start, daily stand-ups, and a review and retrospective at the end, leaner methodologies will enact your demonstration, coordination, and retrospective meetings whenever the stakeholders think that it is appropriate.

Kanban will provide guidance for managing your backlog of work and work-in-progress (WIP). You can turn to other techniques and methods for the exact implementation of other activities since Kanban is generally silent on those.

Answer 2

You are slightly misrepresenting/misunderstanding what the Sprint Planning meeting does in Scrum which I think is the cause of your confusion. A Sprint Planning meeting is usually the wrong place to work out the details of stories. Other than some final tweaks and a quick run-through to make sure there are no outstanding concerns that would significantly impact the estimates, the stories that are considered should be mostly ready to go. From there, the Sprint Planning does what it says on the tin: it plans out what will be in the coming sprint. If you don't have sprints, then there is no need for Sprint Planning.

So when do the details of the stories get fleshed out? Typically via Backlog Grooming or in on-going communications during earlier sprints. The goal here is to get enough clarity so that a reasonably confident estimate can be given. This does not require every detail to be worked out ahead of time. No matter how much you try, there will always be questions that come up during implementation. The goal in Scrum is for the questions that come up during implementation to be relatively minor (essentially, small enough that they don't impact what the estimate would have been).

In Kanban, estimation is optional. If you do estimate, then you are likely to do something similar to Scrum in the sense that before the story is taken on it is discussed to work out an estimate. If you don't do estimation, then the actual behavior is similar except that you may not discuss a story until it is started.

In my experience, I've typically worked on teams that used a Scrum-like approach for the main development and then switched to a more Kanban approach for the maintenance phase. Work in the maintenance phase tends to be more sporadic, and the stories more clearly defined ab initio and smaller scale. In the main development phase, stories often start out at a high-level and need to be refined and broken down to reach a point to where they would be acceptable for a sprint. Starting such stories in a Kanban context makes little sense and would absolutely sink your metrics.

There is no official "Business Analyst" role in either Scrum or Kanban. It's the team that analyzes and estimates stories. If Sprint Planning is the first time the development team is hearing the details of the stories then something is going wrong. I'm not saying you can't utilize a BA or that every developer needs to be in every requirements gathering meeting, but some representation of the developers should occur at some point during requirements gathering before the the Sprint Planning. A BA is usually not knowledgeable enough about the details of the implementation to know the cost of things or what questions might have a significant impact on the cost. This means that there may details that can drastically affect the estimates that won't be recognized until the development team sees them. Further, the developers may be able to provide guidance toward more cost-effective approaches or suggest features that are relatively easy to implement but may add a lot of value for the user. What I suspect might be happening in your case, is that developers are assisting the BA as the BA is doing requirements gathering (e.g. answering questions for the BA or providing some order of magnitude estimates), and that this is roughly replacing Backlog Grooming. Alternatively, you are doing work (e.g. maintenance work) that naturally arrives in relatively small packets, in which case Kanban may well be a more appropriate process.

Answer 3

I am editing my answer based on the feedback I received to further help understand how and when should you be work on the Requirements and Sprint Planning stage of your Sprint; as also on applying the Kanban Method to your current processes. For the purposes of my response, I am using the terms "Kanban" and "Kanban Method" interchangeably, by both of which I mean the recommendations of the Kanban Method. I hope this helps.

---

Firstly, you should not change anything about your Requirements development/ elaboration process "for Kanban" - because Kanban does not make any recommendations there. All Kanban recommends is that you visualize your current processes, including around Requirements management and Sprint Planning, implement WIP Limits and manage Flow. Thereafter, make any changes to your process based on bottlenecks and opportunities for improvement observed.

[I strongly suggest, that if you haven't yet, please read the book - "Kanban: Successful Evolutionary Change for Your Technology Business" by David Anderson, the Kanban Method pioneer. (Full disclaimer - I am a co-founder at a Kanban product company. I am also a Lean Kanban University certified Kanban Coach and Trainer.)

Kanban in itself is not a software development/ project management methodology. Without an existing process, you cannot apply/ implement Kanban. It is a method to help you improve in an evolutionary (gradual, non-disruptive) manner whatever your current processes are. In your case, that is Scrum. So, you should really be applying Kanban on your Scrum processes to help your team improve its software delivery. The combination of this is popularly known as Scrumban.

You would start by following the 3 basic principles of Kanban -

1. Start with what you do now
2. Agree to pursue evolutionary, incremental changes
3. Respect current processes, roles, titles and responsibilities

Using these as your guiding principles, you then implement the standard practices of the Kanban Method - which are -

1. Visualize your current process (and the ongoing work)
2. Limit WIP (Work-in-Progress)
3. Manage Flow
4. Make process policies explicit

Start with these 4 practices. There are 2 other practices defined in the Kanban Method that you can look at once you get started and have a handle on. These are (5) Implement Feedback Loops, and (6) Improve & Evolve Collaboratively, using the Scientific Method.

This is a quick summary - the book will really help you get a better understanding of these. There is also a comprehensive Kanban Guide available on our website.]

The important thing to focus on in your situation is to visualize (on a Kanban board) what you are doing today. Your current Requirements process should be followed during the Sprint Planning process or some sub-steps you might choose to visualize. Your Kanban board should, in fact, reflect the Sprint planning as a specific stage of the overall dev process, followed by technical design, dev and test, as the case may be.

While user stories are in the sprint planning stage, you would follow the steps within that such as the BA providing you details, developers preparing questions and getting them answered before the story moves to the tech design stage and beyond.

(BTW, if your Requirements process has any upstream aspects which might be considered to be part of roadmap planning or backlog grooming, there is a whole topic of "Upstream Kanban" that helps you better manage upstream activities in as much detail as they might exist today. You or your BA/ PO could consider using a separate upstream Kanban board to manage all that activity.)

Your Dev Kanban board flow might look like the one below -

Backlog --> Sprint Planning --> Tech Design --> Dev --> Test --> Integrate --> Done

Each of the stages might have their own "In-Progress" and "Done" sub-columns - although if a single developer takes it thru all the stages, you might not need those sub-columns at each stage. If you feel it is important, you could break Sprint Planning down into 3 sub-stages - Story Detailing, Clarifications, and Done, so potentially you could study bottlenecks in each aspect of the work. For example, in our own dev team, code review can be a bottleneck often!

At the end of your 2 or 3-week sprint cycle, all user stories that are completed can go out collectively - and you start with the next set of stories from the Backlog.

Over a period of time, you might decide that some of the challenges of doing Scrum (story leakage, missed sprint deadlines, etc.) might be dealt with by doing away with some of the constraints/ rules of Scrum - which might appear to be sacrilegious to some. We ourselves do 4-6 week Releases - and don't do Sprints. But equally well, you could just continue to work with Sprints and Releases. In our expperiece, this is where Kanban helps you decide what is right for your business or team and adopt or modify your processes that help you deliver your work in the best possible manner, which maximizes flow, throughput/ velocity and reduces delivery lead times (time to market).

Whether you decide to do away with Sprints and just make Releases as and when a sufficient number of features have been built (or defects fixed or a combination of both) - or whether you keep Sprints - Kanban should help your team work more smoothly, eliminate bottlenecks and improve cycle time performance. If that helps you make more frequent releases which in turn helps you get faster customer feedback, now you are moving to what you might term a "more agile" state of affairs, but which might not necessarily fit the classic definition of the Scrum method.

However, if business goals are being met better, customers are happier and your team is able to function optimally, then you would have achieved your objectives of implementing Kanban.

Hope this helps. If you have any questions, I'd be happy to answer them.

Answer 4

To specifically hone in on your questions ...

what point (In kanban) do the techies and the business folk sit down together to discuss the requirement for the story? Doesnt the Product Manager or BA provide a walkthrough of the Story in Kanban?

The Kanban Method as pioneered by David Anderson does not contain a specific practice or recommendation on when this activities happens. The answer that any Kanban practitioner would provide is that initially when you are adopting The Kanban Method, you should perform this activity in the same way that you perform it before you decided to evolve how you manage work. If you perform it every 2 weeks, you should continue to perform it every 2 weeks.

You're team will discover if there is an opportunity and value in changing the schedule. Remember that 1 month schedule is more agile than 1 year, a 2 week schedule is more agile than 1 month, 1 weeks is more agile than 2 weeks. This thinking eventually gets us to just in time as being the most agile. Being the most agile should not be the target condition before you even start.

With Scrum, the BA is usually avaialble throughout the Sprint to support the development and i assume it is the same with Kanban. It is not clear for me though how with Kanban, the techies understand the Story if there is no sprint planning.

The Kanban Method as a mindset and a set of practices does not place any conditions or constraints on the existence of a Sprint, Sprint Planning meeting, or any other practices. It is completely respectful of a Scrum team and their practices. If you have a meeting today where Techies discuss the story, you would continue to have that meeting, using the same schedule.

I could not in good conscience tell you what the schedule would/should/could be without understanding your team and the organization around it. If you don't perform these activities today, there are many other sources of information to teach you how to do these activities. The Kanban Method can provide guidance on teaching you to discover if your choices are good ones.

Please take a read of the blog posts in these two series. One from myself, and one from Steve Porter, Team member at Scrum.org.

Nothing in Kanban Prevents Scrum - Dave White - WesternDevs.com

Scrum and Kanban - Stronger Together - Steve Porter - Scrum.org

Answer 5

Most of what Mahesh Singh says on top is from the published training material of Lean Kanban Inc. So, really... there is nothing to argue about here. Talk to any AKT or KCP and he/she will say the same thing.

To the original question about where you could do requirement clarifications, there are various options:

1. You could do what you do today but by visualising and putting those steps on a value stream, identify your impediments. Then, make one change and see how that works. Toyota Kata community calls this as single factor experiments.

2. Do an upstream Board for Requirement refining, decomposition, UX/interaction designing, etc. In our own team, we break Themes to Epics, do the full UX design cycle and only then break it into stories. Then, the stories are prioritised by getting all stakeholders in a meeting. The end of this value stream results in refined, prioritised stories. That constitutes our backlog for the development team. In fact, this flow takes a lot of cycle time, mainly because it takes time to move from a Epic level requirement to wireframes in Sketch or Zeppelin for the Dev team.

3. If you don't have a significant value stream or cycle time to convert something from requirment to refined stories, then you could simply have a stage in your Development value stream (like Requirement clarification). However, Scrum does expect high level of clarity for estimation and breaking into tasks. So, whether you do a meeting ahead of the Sprint planning meeting or do an extended Sprint planning meeting, it will depend on your team and organisation.

If we remember the principles and are open on the defined practices, the Inspect and Adapt cycle becomes much easier.