Tag Info

There is no clear indicator this question belongs to Sprint Backlog only. I believe this is wrong. The urgency of the work, to me, implies that it cannot wait until the next Sprint. The team must bring this work into the current Sprint and therefore is responsible for making the determination on increasing the WIP limits. Since the Development Team owns ...

Update: This Answer assumes, incorrectly, that by WIP the OP meant Sprint capacity (a limit on how much work can be included in a Sprint), not Kanban WIP limits (a limit on how much work can exist in a single status at a time). I'm leaving it for posterity, but it does not answer this Question. I would argue that the only valid answer is: No one, as '...

I would say it really depends on the context - there are no "rules" that Kanban enforces - it is up to the team and the business stakeholders to decide. If it is happening on a regular basis, then, they should look at the WIP Limits and enforcement related policies to see if these need to change to accommodate this phenomenon. For the example you have ...

TL;DR In agile frameworks such as Kanban, you shouldn't have to care about how the work is allocated within a process state such as "development." That's up to the team. Just focus on right-sizing the WIP limits to ensure they are based on available team capacity and optimize for flow rather than individualized tasking. Limit Work to Optimize Flow From a ...

There are a lot of theories that go into The Phoenix Project. Queuing theory is the underpinning of most everything else. It is very old (origins in 1909) and is used to great success in almost every industry from factories to computer science to retail. I don't know if there is any type of systems theory out there anymore that doesn't include some aspect of ...

One of the possible answers here is planning and monitoring (actually nothing new to project management) TLDR: plan your journey, check yor location and plan (the more frequent you do so - less surprises you have), adjust your direction. So, to handle the situation it is worth to have a set of triggers to activate a subsequent team. Basically in task ...

WIP limits are needed to balance 2+ steps of the workflow. So that the constraining step (the bottleneck) doesn't get overloaded. So if you know the team and have a rough idea of who's going to be the Constraint - set the limit to the number of people in that group + some buffer (buffer size depends on the typical duration of tasks). That's provided that the ...

It's better to have each project with its own board, otherwise things can become confusing, or you might miss some things as one team thinks another team "has that one". Also, it will be hard to manage the WIP limits because it's a sum of WIP limits in fact, and the sum can hide some problems with the individual WIP limits that compose it. For ...

The existing Answers are good, I just wanted to add something on top of them. As you're doing Scrumban, I am assuming/hoping that you are performing the Scrum event known as the Retrospective (often considered to be the single most important part of Scrum). Therefore, whatever you take away from this, other research, and your own internal musings, I suggest ...

I would like to challenge your assumption that this has anything to do with the WIP-Limit. Lets say you have 5 full time developers and 2 part time developers. And for starters, you set the WIP limit to 7, so that each can concentrate fully on their one task until it's done. Whether or not the part timers are there on any given day does not change ...

I believe there's a simple solution: All Part timers must pair program with full-time developers...all the time. But that seems heavy handed? I have worked with teams that pair on all work and it has been highly effective. The developers will need to think carefully about how they pair to ensure they maximise the benefits of this approach. There are lots ...

I just wanted to add a little to Mahesh's excellent answer. As well as making value based decisions in this kind of situation it is also worth considering how to avoid the situation in the first place. One aspect of team synchronisation is to think about the sequence in which the work will be done. There are many factors in this, including: Availability ...

My answer would be No one, as 'High Priority' work is not a valid reason for changing the WIP during the Sprint. The WIP limit, as in the number of tickets that can be in a particular status of development (a column on the board) is not determined by the urgency of the work but by the amount of work that the team can be working on at the same time ...

My other Answer answers a different question that the OP has clarified is not what was intended to be asked. I'm leaving it for posterity. This Answer addresses changing the Kanban WIP limits during a Sprint. In this case, I would argue that the best answer is not actually listed. There are two aspects to this issue. What to do about this particular high-...