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

I don't want to argue the talk - he actually does a great job in my opinion of making the case for a more empirical process of prediction. However, he sort of throws out a false message in that he poses the question of project completion forecasting at the beginning then focuses on cycle time without ever answering the original question. From my own Kanban ...


2

The simple answer: you want to measure cycle time against your backlog items, not the tasks under those. The goal is to measure how long it is taking to deliver a unit of work. Tasks are just things you do, not units of work being delivered. Your cycle time will vary by the size of the item, that isn't a problem. You want to look at your cycle time on a ...


2

You might use Logging time. As defined in ITIL, this is the Process to record and prioritize the Incident with appropriate diligence, in order to facilitate a swift and effective resolution. More info at https://wiki.en.it-processmaps.com/index.php/Incident_Management As a side note, I'd suggest to use the whole nomenclature already defined by ITIL. It'll ...


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 first thing you need to ask yourself is for what reason your Team is tracking cycle time. If you're not currently tracking cycle time for tasks/subtasks, and you don't have any problems with doing so, then I see no reason for you start now. If you do need to track them for whatever reason, then I suggest using a rolling average - you take the average of ...


1

Control Charts Primarily Visualize Process Variability While they show you some nice things like lead time and cycle time, the most beneficial metric that can come out of using a control chart is variability, and from that, the predictability of your process to produce value for your customers. Teams can better understand their variability by inspecting '...


Only top voted, non community-wiki answers of a minimum length are eligible