10
In a word: feedback.
Whether you’re coaching a soccer team, flying a drone, planning a city, or writing a dissertation, the sooner you can get feedback, make adjustments, and get more feedback, the more successful you’ll be.
In Kanban, you get feedback by completing stories and observing how they affect the system. A smaller story can be done faster, ...
9
Embrace Change but Keep Costs Visible
"What happens when we're at our WIP limit and 'do it now' work crops up?"
If you've structured your process with spare capacity, rather than striving for 100% utilization, some Kanban processes allow for a special high-priority queue (sometimes called a "silver bullet") with a WIP limit of 1.
Some slack is essential ...
7
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 ...
6
Is this reasonable?
In my personal experience the answer to that is no. WIP limits exist for a number of very good reasons, one of which is to identify bottlenecks such as that which you have described.
If the hardware is necessary for the HW testing to be completed then by creating a swimlane with limitless WIP you're establishing something of a false ...
5
To contribute and also help move the discussion forward, let's first start with the definition of WIP:
WIP is the number of task items that a team is currently working on.
When rolling out a new workflow, you monitor the average number of task items in each iteration and determine the WIP limits. However, it is not possible to know if the WIP limit is ...
4
TL;DR
To the very best of my knowledge, there is no canonical formula for determining Work in Progress (WIP) limits. However, there are some empirical best-practices.
What WIP Limits Are Intended to Do
The goals of WIP limits are generally to:
Improve throughput.
Reduce cycle times.
Optimize team capacity.
Limit the efficiency drag from multi-tasking.
...
4
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 '...
3
Little's Law is most commonly used to explain why the practices in Kanban exist. As you point out, you can just calculate the average cycle time and don't need Little's Law to tell you what it is.
Now, you say your WIP is 3. I think you are conflating WIP with WIP limit. WIP limit is a set number but you should not be at your limit at all times. But for a ...
3
If you have to exceed the limits for some reason, increase the limits, get the work done and then decrease them again. It is easier to remember the rule "Never exceed limits" than "Sometimes it's okay". Alternatively, allow "Expedite" lane at the top, but make sure to only expedite critical issues, not business-related stuff. If you're always expediting, ...
3
First let us consider why work in progress is limited. Limiting WIP is needed in order to establish a self-regulated system that balances capacity and demand throughout the value delivery stream.
Simply put - if you see too much WIP, this means that somewhere down the line there is resource shortage. The most proper way is to address the resource shortage ...
2
The fact that Team A uses Kanban and Team B uses Scrum is probably incidental to the situation. Fundamentally, the two teams have a different attitude towards quality of their work and its impact on their customers. Besides impacting Team A's performance, they may also be impacting their external customers, which management may not even be aware of.
The ...
2
Jira Activity stream has also a table view, which looks similar to what you requested:
To get that, Add Gadget to your Jira Dashboard and then use toolbar (seen on my screenshot) within the "Activity Stream" to switch to table view.
2
You can use the Jira Activity Stream gadget
Yes, Jira has a built-in gadget to do this. It is the Activity Stream gadget:
You can add this gadget to your Dashboard and select all the projects that you want to track. I find this gadget very convenient to track all Jira and Confluence activities as a stream in the dashboard.
However, please note that I am ...
2
I would take a look at the Jira tempo plugin, it will solve all your time tracking and recording issues. We also combined it with the worklog assistant, since not everyone likes to book hours, this will simplify it a lot.
List of recent work-items per project: https://tempoplugin.jira.com/wiki/display/TEMPO/List+View
Team time-sheets: https://tempoplugin....
2
You could add a column without WIP Limit in front of the test column.
Example for columns TODO | Implementation | Implementation Done | Test | Done
The item would then rest in Implementation Done until the HW arrives and someone picks it up. This state would also be highlighted in some way. We use different Magnets on our board: Colors/Symbols - Team ...
2
Adding a "Waiting on Hardware" zone at the bottom of your Testing column could be a workable approach. It would allow you keep you WIP limit as a firm limit while still showing the backlog in the correct area of responsibility. Color coding the overhang/delayed demand to highlight it for everyone is probably a good idea. In a way, you are moving it off the ...
2
I have found that temporary fixes (like ignoring low-priority stories) often end up being long-lived.
Better to get your board to a good place first, then work to optimise the WIP limits.
The downside of this is that some high priority stories will be delayed, but the benefits include:
Fewer items on the board, so it is easier to see what is going on
It ...
2
Work in Progress is a critical part of Kanban because of Little's Law. You are welcome to read more about it, but the short version is it shows a direct relationship between throughput, response time, and work in progress. By limiting your work-in-progress and focusing on flow (and prioritizing getting things to done over getting started or keeping people ...
2
Limiting work in progress is a cornerstone of Kanban because:
It helps to emphasise that Kanban is a 'pull' process
It is often a very effective way to improve the throughput of work for a team
It is simple and easy to implement
It combines well with another feature of Kanban: visualisation of a process using a Kanban board
2
To effectively answer this, we have to remember that the purpose of a Kanban board is to visualize the flow of work. It is not quite as 1-to-1 as each column being a step of work, but that's a good place to start.
A and C are fine because they are not columns per se. A is part of the Development step and C is part of the Testing step. The soft line just ...
1
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 ...
1
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 ...
1
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 ...
1
The definition of Work in Progress (WIP) is: Work that has been started, but not yet finished.
The reason why we want WIP to be minimized are:
To help the development team to focus and minimize context switching.
To minimize incomplete, carried-forward stories at the end of the sprint.
The way I implement this in my team is: Whenever any developer has ...
1
Throughput in Kanban refers to the amount of work delivered over a certain period. No matter how many work items your team has in progress, this metric ignores anything unfinished.
Consider a workflow where throughput is calculated on a weekly basis (you can use any time range, but you should compare throughput of a team using the same range). In five weeks,...
1
Kanban originated in the manufacturing industry
In the manufacturing industry excess Work in Progress (WIP) has many disadvantages:
High inventory carrying costs
Risk of obsoletion
Risk of dead inventory when a different model is scheduled
In the Kanban system you keep only enough Finished Goods (FG) inventory to meet actual demand. Working backwards, at ...
1
I believe the following quote is clear:
Limiting WIP is the cornerstone of Kanban. Limiting work-in-progress
implies that a pull system is implemented. Put limits on columns in
which work is being performed. The critical elements are that
work-in-progress at each state in the workflow is limited and that new
work is “pulled” into the next step ...
1
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 ...
1
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-...
1
Many of your ideas are based on faulty assumptions.
S meaning small enough to fit into iteration which also does not apply to Kanban
and
The rule of thumb is generally that a story should move through the system in 2-3 days.
You link to the Agile Alliance page that defines INVEST. However, that page links to the XP123 blog post by Bill Wake that ...
Only top voted, non community-wiki answers of a minimum length are eligible
