8

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.

  • In normal Scrum or Kanban, BAs, Product Owners or whatever work with the team ALL THE TIME, not only at beginning of the sprint. Stories should provide enough information for rough understanding by the team, but any details should be fleshed out by BAs or POs during the implementation of the story. – Euphoric Jul 7 '17 at 18:16
  • I know that they (BAs/POs) are available throughout the development but with Scrum, the development starts off with the Sprint Planning where the BA/PO gives a general overview of the Story. Presumably this happens at some point with Kanban but it is just not labeled as "Sprint Planning". – ziggy Jul 7 '17 at 18:20
  • @ziggy Where are you getting your kanban information from? what are you reading? – Dave White Jul 11 '17 at 16:12
15

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:

Advanced/Lean DAD Lifecycle

Continuous Delivery DAD Lifecycle

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:

Basic/Agile DAD Lifecycle Extending Scrum

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.

  • Thanks Thomas - For us, the initial "modeling, planning and organization" phase shown in your diagram is done outside of the sprint as a pre-planning step. It involves PO/BA (as well as scrum master and architect). For this reason, the first time the Dev and QA teams know about the new requirements/features is at the point of Sprint Planning. – ziggy Jul 8 '17 at 9:42
  • @ziggy I added the diagram that captures Scrum in the same Disciplined Agile framework. "Initial modeling, planning, and organization" is what many teams call "Sprint 0" (which isn't part of Scrum at all - Scrum is silent on project inception activities). The "iteration planning session" is your Backlog Refinement (grooming) and Sprint Planning. In Scrum, Sprint Planning happens on a particular cadence. In a leaner process, "Coordination Meeting" and "Replenishment Modeling Session" includes planning and stand-up and happens when necessary, not on a particular cadence. (1/2) – Thomas Owens Jul 8 '17 at 10:01
  • @ziggy Note that Disciplined Agile is its own framework, so it doesn't use the Scrum framework terms. That's why there's a little bit of mapping. DA is a framework that supports a variety of agile and lean product development processes. It should be close enough for you to map your existing Scrum work to the things in the third diagram, and then see how all the timeboxes and iterations are gone once you move to a leaner process, yet all of the work remains done. (2/2) – Thomas Owens Jul 8 '17 at 10:11
5

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.

  • Thanks Derek. Yes we do "Backlog Grooming" but we call them Pre-Planning session. The Pre-Planning sessions does not include all the teams (Because the team is fully involved on the current active sprint). For this reason, the Developers/QA teams only know about the new features/requirements at the point of Sprint Planning. Sometimes it can take up to 2 days of back and forth Q&A sessions for the team to fully understand the requirements and being able to start "solutionising" a problem. – ziggy Jul 8 '17 at 9:46
  • @ziggy Does this mean that the developers/QA are doing all the estimation in the Sprint Planning meeting, or is someone other than the developers/QA doing the estimation, e.g. the BA? A situation like this would seem to give development and QA very little time to make their own estimates before they then need to commit to delivering. – Derek Elkins Jul 8 '17 at 12:44
  • What you're describing is not-Scrum. Check the Scrum guide. There's no pre-planning meeting and definitely estimation is the team's responsibility. Not a BA and one team member who probably won't even be doing the work. This is a huge red flag for project management in my view. Management clearly wants to pick and choose who gives the estimates so that they'll get the estimates they want. The team is left scrambling to either argue about the estimates or kill themselves trying to meet unrealistic deadlines. – RibaldEddie Jul 10 '17 at 22:05
  • @RibaldEddie Is this comment directed at ziggy or at the answer? – Derek Elkins Jul 10 '17 at 22:48
  • @DerekElkins both. – RibaldEddie Jul 11 '17 at 3:25
2

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.

  • 2
    This post has a lot of problems. Right off the top, David Anderson is not a "Kanban Method pioneer". Kanban was developed by Taiichi Ohno as part of the Toyota Production System and lean manufacturing, which was adopted into lean software development (and other variations for various environments). Then, a lot of what you describe isn't Kanban - it's TPS, lean, and Kaizen. Kanban is simply a method of scheduling and managing work, nothing about "evolutionary, incremental changes" (that's Kaizen). Only the first 3 of your Kanban practices and principles are actually part of Kanban. – Thomas Owens Jul 8 '17 at 1:32
  • 2
    This is a well-written overview of moving to a Scrumban process, but it doesn't seem to directly answer the question “When does the team discuss requirements when using Kanban?” (Except indirectly via “Kanban in itself is not a software development/project management methodology.”) You don't even mention requirements once! Please edit your answer to address this main question more clearly. – amon Jul 8 '17 at 13:35
  • Thanks for your feedback. Just to clarify, I have mentioned David not as kanban pioneer, which of course came from the various sources mentioned by Thomas, but the "Kanban Method" for knowledge work pioneer which David laid out in great detail in his first book that I have listed in the post. I agree that I did not focus so much on Requirements (which I will fix) but I felt that the questioner's experience with Kanban - or possibly the lack of it - needed to be addressed and I guess I focused more on that. – Mahesh Singh Jul 9 '17 at 20:46
  • 1
    @ThomasOwens Your critique of this answer has nothing to do with the actual value of the answer to the original question. And also points to a narrow view of what Kanban is. David Anderson is the pioneer of "The Kanban Method". He did not create the chinese/japanese word 'kanban'. Taiichi Ohno didn't create that word either. Ohno, Deming and Shewart are the 'fathers' of the lean movement in the world of manufacturing, but they did no work in applying lean to knowledge work contexts, which 'The Kanban Method' is. – Dave White Jul 11 '17 at 16:38
  • 1
    @amon The question of 'when' was answered by Mahesh when he said that a kanban team will follow their current process exactly as it is. 'The Kanban Method' directs a team to respect the current process until it understands what and why it is going to change something. – Dave White Jul 11 '17 at 16:41
2

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

1

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.

protected by gnat Jul 11 '17 at 4:27

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.