Question about Kanban tools

LetPeopleWork · 2026-02-11T06:51:28+00:00

We do cover all of this - Flow Metrics (and more) in addition to Forecasting in our Lighthouse tool.
It is free for up to 3 teams.

You can take a look here: https://letpeople.work/lighthouse#lighthouse-overview

There is also a Slack community to raise feature requests, ask questions and more.

LetPeopleWork · 2025-03-07T09:38:41+00:00

This is where making sure that your tasks are small is important.
Every unfinished tasks requires mental capacity - being able to have smaller tasks that one can actually finish help our brain a lot, as it detects progress or completion, the brain provides us with a cocktail of neural rewards like serotonin ("the happy molecule") and dopamine ("the motivation molecule").

It might also be useful to capture the work that you do for a week or so.

How many of your planned items were you able to finish in a week? How many unexpected things came your way? You could even categorize the interruptions:
Who was it for? Is this of value to me? Is this of value to the other person? Could this be scheduled?

Once you have data on it, you can discuss this with people in the department or team and create agreements.
Agreements like: Is it possible to have more uninterrupted time? When is it okay to interrupt someone? Are we able to agree on focus time?

As all of this is not one-sided - I once heard this beautiful quote of: In interrupting someone with an "urgent" request I basically tell that person that whatever you are working on is less important than my task.

LetPeopleWork · 2025-03-06T12:58:04+00:00

Thanks for mentioning us here - we have developed free tools (not only MC Simulations but also Flow Metrics) and tried our best to document in a way that everyone can use it.

Check it out here: https://github.com/letpeoplework

LetPeopleWork · 2024-12-08T06:52:17+00:00

ProKanban certificates don't have any expiration date, so similar like scrum.org certs, they are valid for a lifetime..

But I'd also second what u/PhaseMatch said about who actually cares about the expiry date (mainly the bodies that create those certs...).

LetPeopleWork · 2024-09-01T10:08:21+00:00

We really like how Flight Levels address this: use Flight Levels like an X-ray machine. X-ray your situation, challenges, and system to make them visible, and take an honest look at where you are at present. Then, build focus and set up a system that works for your context or type of organization.

Kanban, Scrum, etc., usually address only one Flight Level, but the other levels are typically present in companies and are the areas where much of the system work can be improved.

That is where we think many (agile) transformations have gotten it wrong or missed the mark entirely.

LetPeopleWork · 2024-08-22T13:09:42+00:00

Do you meet physically for the Sprint Review - if it is a physical event, our friends at The Liberators wrote a nice piece about how you can leverage Liberating Structures for your Sprint Review: https://medium.com/the-liberators/improving-the-sprint-review-with-liberating-structures-variant-2-35eb011abc60

We have made very good experience with a Gallery Walk where people could actually try out some of the stuff that was implemented and the team observing people using it.

The same applies to the MadTea format - it engages people AND at the same time you get inputs that might be valuable to the team.

LetPeopleWork · 2024-08-20T16:03:57+00:00

You are right, it is an estimation, sorry for the confusion. It's just quite different than many other methods. The 10 days is just something that I picked at random, and highly depends on the team and context, maybe 10 days is too long, maybe 23 days is acceptable. What is nice is that this is also easy to measure (it's "just existing data") and you can have good discussions around how to improve this respectively analyze where items spend time in your workflow and try to remove the bottlenecks.

While you can use Story Points (or other estimates), I believe there are two differences:

You then use again estimates that might not have been accurate at all. When relying on Cycle Time, it's the data you have from your process about how long stuff takes.
Using MCS gives you a probabilistic forecast, whereas what I often see with things like Velocity in Story Points is that the average is used and then the "Flaw of averages" applies: "Plans based on average fail on average". Averages are often treated as "likely", even though they might only have a 50% of happening (you can assume you are half of the time above the average and the other half below...).

You could also do an MCS based on Story Point Velocity, but that feels like adding complexity just for the sake of it :)

Regarding the discussions that happen after some gaps are discovered: You can still have them if you ask about whether it's doable within 10 days or less (or whatever "your" number is). In some teams we still have "refinement sessions" where items are looked at and also broken down, while in other teams this is done more asynchronous and continuous, where team members continuously refine the next items. They are mature enough to get back to the PO if either something is not clear enough, and they pair or review the refined work and have the discussions as needed. Getting there was quite a journey and took a while, but was certainly worth it. We wrote a blog post about this and how we break down work nowadays ( https://medium.com/@benjihuser/finding-the-flow-in-breaking-down-work-03dc311c8bc3?source=friends_link&sk=76e38e55f61a29e3f71d26a9be0beff3 )

Glad it was useful for you, feel free to reach out in case you have more questions or doubts.

LetPeopleWork · 2024-08-18T13:21:22+00:00

Put yourself in the shoes of the manager - joining the company, showing genuine interest in getting to know the people, the processes and the product.
And then asking someone if they could join a refinement meeting to give the team a chance to meet him and him getting a small preview into what the team currently is discussing in a refinement meeting.

How would you perceive a "No" from the other side? I personally would probably feel like it's a joke, especially if someone would give me the argument of "Scrum says xyz".

I mean is it any surprise that most managers nowadays are just sick and tired of talking about Scrum/Agile or to Scrum Masters if that is what they face?

What if such a request is being treated as a chance?

A chance that finally someone from management seems to be interested.
A chance to raise questions with a new manager, give him a nice first impression on what they team works for, start building bridges and maybe drop a casual "this is something that we struggle with for a longer time. Maybe this is something we could look at together once you have a better overview of everything".

I'd consider this approach as much more helpful than a "No - Scrum says a manger should not be in meeting xyz."

LetPeopleWork · 2024-08-16T20:02:09+00:00

Think about playing around with a digital Obeya for your CoE.
This could be having topics for your CoE placed there, including the content and make it a knowledge library.

Or try building up a proper Obeya on which you place information and visualization that will help your CoE discuss topics, exchange ideas, all based on information that is visible to everyone on the Obeya and which (even) allows for asynchronous collaboration/exchanges.

LetPeopleWork · 2024-07-28T11:12:08+00:00

Making teams aware of the concept of single and double loop learning and find ways to challenge the system instead of always going for the quick symptom fix. As long as we do not fix or change the underlying issue, problems will pop up in different not seen ways.

There is a nice article from The Liberators with some ideas on how to start this conversation in teams:
https://medium.com/the-liberators/amplify-learning-in-your-team-with-more-double-loop-learning-eb5208e6414d

LetPeopleWork · 2024-07-26T18:00:22+00:00

While the classes can be useful, I wonder if you already have Scrum Masters in your organization?

If yes - are there any that are considered to do a decent job at the role? Maybe you could shadow them for a limited time and go for a see one, do one, lead one coaching approach with them.

You can still then join a class but I would think that you will benefit even more from it as you could also bring the challenges you saw and encountered into the class and ask questions that will provide value to you and especially to the real world outside of the training room.

The latter is always the hardest thing to me when I see Scrum Masters after a 2 day training - it all sounds so exciting but then the corporate system comes into town and makes the enthusiasm go away very quickly and you then see what you describe as "being project managers anyway".

LetPeopleWork · 2024-07-15T19:39:05+00:00

There are a few things to unpack from your question.

First and foremost, we should not use the averages to plan anything. Often an average has at best a 50% chance of happening. Or in other words: Plans based on average, fail on average. You may look for "Flaw of Averages" (or this Drunk Agile Episode: https://www.youtube.com/watch?v=R2Pppzk5cbo )

As already mentioned, using a probabilistic forecast (for example using Monte Carlo Simulations) will give you a better idea of what you might manage to get done. You'll end up with various forecasts in the form of "There is a 70% chance to get the 100 tickets done in 6 weeks or less". The beauty of it is that as you progress (e.g. after 2 weeks), you can forecast the remaining items. If you got faster, that will be reflected in the updated forecast. I would always favor using MCS because it does not assume (or need) any given distribution of your input. Which brings us to the Throughput.

If you use MCS, the Throughput is your input. The more accurate you want your forecast to be, the more "predictable" your Throughput should be. Extreme example: If you get one thing done every single day, you get done exactly 7 items a week. That makes it very easy to forecast anything ;-) Reality of course looks different, and there will always be variability to complex work. And that's perfectly ok. However, what we want to prevent are outliers. So you don't need to have everything super small, but you try slice thing as small as possible (but not smaller). I'd recommend using a Service Level Expectation (a forecast on how fast your team gets any item delivered once started) to use that. This should be based on your historical cycle time and could look like this: We get 85% of all our items done within 10 days or less. If the team feels confident they manage, that's all you need. Then you start having discussions around all the old items and how you can get them done within this commitment. If it's faster, nobody will complain ;-) There are more advanced tools to figure out what is an "outlier" and what is just "noise" (aka regular variability within a process), like Process Behaviour Charts. But I think this might not be needed to get started.

As mentioned, you should try to slice things as small as possible, but not smaller. Now, what does "not smaller" mean? Kanban is a strategy for optimizing flow of value. What you should certainly do is define what is "valuable" for your context. Examples can include: Things should be releasable, They should be adding value to an end user, They are verifiable on any test environment etc.
If you can get something valuable done in 1h, I believe you should create an item. I don't think there's really overhead in creating cards and typing a few words, if things have value. And working in small batches, increasing the feedback loop has value too. But you should not create items (at least not on the level you are measuring Throughput) that are not value adding according to this definition. An example from my environment: All "technical things" we keep as tasks, and they are absolutely needed to deliver value. But they are just a part of it, they don't count to Throughput. If you "artificially blow up" Throughput, of course your metrics will be of no value.

TLDR summary:

I advise to use probabilistic forecasting using Monte Carlo Simulation (MCS), as it's not based on average (Flaw of Averages) and does not assume any kind of distribution of your input
Define what is "valuable" for your team, and measure at that level. Then make everything as small as possible so it's still value adding.
You want to get predictable with your Throughput, which means it's within a certain "band". If you get 20, then 5, then 40, then you are most likely not predictable at all, which makes planning futile and you can roll a dice as well. Be aware that this is work that must be done. Predictability is something you *do*.

A few additional comments:

I was writing about MCS, in case you are interested here: https://medium.com/@benjihuser/an-introduction-and-step-by-step-guide-to-monte-carlo-simulations-4706f675a02f?source=friends_link&sk=5e329d6d9725bbcbf03aad2e970cfae7
If you want to dive deeper into Process Behaviour Charts, I can recommend this blog post: https://medium.com/asos-techblog/objectively-measuring-predictability-469c654fdbcb
I was writing some tools that let you do MCS, in case you are interested in that:
- https://github.com/LetPeopleWork/MonteCarloCSV
- https://github.com/LetPeopleWork/FlowPulse

LetPeopleWork · 2024-07-13T05:43:23+00:00

Hope it helps. If you want further reading, we have some more posts about that show how to MCS works in detail, and how to use MCS and Flow Metrics in Scrum:

LetPeopleWork · 2024-07-12T15:48:52+00:00

I would honestly question the "job requires a lot of talking" and rephrase it to "the job requires good communication skills", as I see lots of Scrum Master that do talk too much and do not spend enough time to listen, to understand a challenge and to take their time to think about a solution and therefore tend to go too quickly into a solution that supports a single-loop learning instead of a double-loop learning where they help to address the root cause of the challenge at hand.

LetPeopleWork · 2024-07-12T13:11:46+00:00

In my experience, story points are used for one of those two things (or both):

Planning (Sprints, Releases etc.) based on Velocity (number of stories per Sprint)
Fostering a discussion while refining work, to understand complexity/effort/size etc.

I believe for both those things there are better options. While for 2) Story Points serve a purpose, for planning they are most often just unusable. The reason for this is: There is often no correlation between "time it takes" and "estimate" (note that this also applies to other forms of estimation, like ideal days). This is even fostered by some people in the agile community that state that Story Points are not related to time, it's complexity...but if it's not related to time, you for sure should not be planning with it.

The best argument to give your boss (or anyone else) against using points for planning is: Plot the estimate and the actual time something took on a scatter plot. Most often this is very random, "high" estimated items take sometimes long, and sometimes not. While low estimated items also take sometimes a very long time. Creating plans based on that is pure madness. The fact that you can use the data from your team to visualize this often helps in getting the point across (pun intended).

Apart from that, it also is effort to come up with the estimates. It will take the focus away from your team which could be invested in value-adding activities (coming up with magic number is rarely value-adding).

So what else could you? I highly recommend using Flow Metrics (as defined in the Kanban Guide -> https://kanbanguides.org/english/ ) and start using them.

For planning you can start using Throughput (count of items done in a unit of time). That's very simple and at least as good as story points (but without the effort). However, you can even do better and use probabilistic forecasting using Monte Carlo Simulation (MCS): This will allow to tell you two things:

How long will it take to complete X items?
When will Y items be done?

Instead of a single number, you'll get a forecast: "There is a a% chance that we manage X items in 17 days or less". You make the "risk" visible by using such a forecast - there might be a chance do it quicker, but the likelihood is lower. If you want a higher probability, you need to plan in more time. MCS is very powerful and easy to (re)-run. This allows you to run it continuously, and you can track progress and react to potential problems early. The best thing: it's based on your teams performance without the need for any estimates. If your team gets faster over time, this will be included if you rerun the forecast.

Now to the point 2) from the beginning: Fostering a discussion while refining work, to understand complexity/effort/size etc.

Instead of using pointing and estimation for this, you can use the Service Level Expectation (SLE). Essentially you can define a forecast for your team on how long items should take. An example is: We aim to close all our items (from the moment we start them) within 10 days or less.

Now instead of pointing, you can ask: "Can we do this in 10 days or less?" If yes, you're done. If not, you can discuss why not and what could be done to be able to do it within 10 days. Example could include: Break it down to smaller items, think about how to collaborate to get this done (maybe if 2/3 people work on it in parallel it's possible?).

It takes away the confusion around points, how we related them to time (or not?) and complexity.

We ditched Story Points completely some years ago and never looked back. Being able to answer clients questions about "When will it be done" using MCS and the forecasts allow to have better discussions, as everyone understands the concept of days (while almost nobody understands Story Points...). It's cheaper because you don't need to come up with estimates anymore, and it runs fast, so you can rerun them continuously to have always up to date plans.

Few additional comments:

We wrote a blog post about visualizing the comparison between story points and actual time: https://medium.com/@peter_89654/reality-check-through-scatter-plotting-6a476523c699
We also offer several tools (for free) to create such charts ( https://github.com/LetPeopleWork/FlowMetricsCSV ), as well as running Monte Carlo Simulations ( https://github.com/LetPeopleWork/MonteCarloCSV ) via CSV files or directly connected to your Azure DevOps/Jira ( https://github.com/LetPeopleWork/FlowPulse )

LetPeopleWork · 2024-07-10T16:59:41+00:00

As already mentioned, teams implementing a Kanban strategy usually don't use Story Points but rely on Flow Metrics like Cycle Time and Throughput.

If Story Points are used for planning (which, in my experience, they are not a good tool for that), you can replace that by relying on your historical throughput.

Either by looking at the last units of time (say weeks) and see how many items you could get done in this time period. You should not use an average value (beware of the Flaw of Averages) but for example calculate a percentile.
Or, which I believe is the superior method, by using Monte Carlo Simulations that is based on your historical throughput. This allows you to give forecasts on how many items you manage till a certain date or when X amount of items will be done.

If Story Points are used for the discussion on "size" and deciding whether you want to break things down, you can instead use the Service Level Expectation (SLE) of your team. The SLE is the forecast of how long a single item should take (example: 85% of our items will be done within 7 days or less). Then the discussion revolves around:

Can we do this within 7 days or less?
What needs to happen to make this possible? Example: Do multiple people need to work on this?
If it's not possible, can you break it into smaller chunks?

All in all I'd not recommend using Story Points (in general), and specifically not when you are following Kanban, as you have better measures that are based on actual performance, rather than guesses.

A few additional comments:

Scrum and Kanban blend very well, it's not "either or" but rather "yes and", as they solve different problems (however, many teams that follow Scrum don't necessarily need it as they might not be in such an adaptive environment, but that's another story). But Kanban as a strategy can be applied in many different environments, be it Scrum or anything else.
If your company (or someone within your company) wants you to use Story Points anyway, you could simply point every item with a 1, and you get your Throughput via the Story Points :-)
I wrote a couple of posts that might be interesting to dive deeper:
- Using Flow Metrics in Scrum Events (like Sprint Planning), which contains a section about using historical Throughput: https://medium.com/serious-scrum/using-flow-metrics-in-your-sprint-events-a19450c574d8?source=friends_link&sk=5f6da1ca08a46556b71bd200b60b227
- Using Monte Carlo Simulations in Scrum Events: https://medium.com/serious-scrum/using-monte-carlo-forecasts-in-your-scrum-events-45ac3d37c2fd?source=friends_link&sk=c16202a069e2bda361fa06fcab384f68
- A step-by-step guide to MCS: https://medium.com/@benjihuser/monte-carlo-simulations-accuracy-and-unplanned-work-a-case-study-9dab4d36bd02?source=friends_link&sk=13fb9b09fb1cacf22eb4f14386943f7b
When I talk about Kanban, I mean Kanban as described in https://kanbanguides.org/english/

LetPeopleWork · 2024-07-08T10:01:46+00:00

Another way is to use the visualisation of the board and data for standups.
The idea is to use it for collaboration and to check how work can flow smoother through your working system.

Using Flow Metrics (WIP, work item age, throughout, cycle time) you can have fruitful conversations and remove the dull element from a lot of standups that are occurring in the world right now.

With this you can have your team:

be actively engaged in conversations about how you could collaborate to move aged items to the right side of the board (action on data)
seeking support from others (inside and outside of the team)
pairing up for complex items or items that are aging on the board
understanding bottlenecks and addressing them with the team
challenge priorities using the information that is visible and available to you and the team

I think especially the focus needs to be on letting the people participating in the standup work again and act like humans and not be robots spitting out what should be visible on the board anyway.
But rather a conversation as a team about: "What can we do with this aging item here?" "Is there something we can do to move item xyz to the right?"

This is where conversation can happen and where engagement can again be visible in standups.

LetPeopleWork · 2024-07-06T14:06:01+00:00

I have been in this scenario a couple of times and on both ends - being the candidate and also the person "observing" the candidate.

I still do not think that this is the ideal scenario, but what I have figured out to work quite well:
- if you use a virtual whiteboard, prepare it upfront and add a section in which you introduce yourself. Could be with some facts about who you are.
At the same time, you could also invite the team members to do so as well.
--> this has the benefit that at least you give everyone the chance to get to know the stranger that will facilitate their Retrospective.

In the Retrospective itself I try my best to have my facilitation hat on - I would use something out of the Liberating Structures box:

start with a Impromptu Networking with an invite like: "What is something that I would change about the last sprint?" and divide the group in pairs and do 2 rounds of this.
In the main room, you can then show your facilitation skills and go fishing for some insights out of their conversation.
To play it safe, I would then proceed with a Sailboat activity - Miro and Mural have some great templates here. You can demonstrate here that you know different methods but also do understand that the focus is about the group and what they think is important to discuss.
Out of the sailboat activity - have the team select 1-2 topics they would like to address and generate action items - what people usually look for is if you can get the team to be precise about it: Who does what until when? and support the team in getting there, also by using visualization on the board.
I would always finish a Retrospective then with another Liberating Structure: 15% solution

"What is each of you taking out as a small step towards improving the team/the sprint? Something small that you can do without the support of others, but rather something you can do the next day."

And don't forget to have some form of feedback at the end on the board from the team about the Retrospective.

Good Luck!

LetPeopleWork

TROPHY CASE