5

As per Kanban, estimations are considered as waste but from the business perspective we need estimation and there is no way to keep features similarly sized. S, M, L sizing does not work as well because executives want to have duration estimates, some variance is acceptable (3 days for example).

At this moment we use task count as buckets of durations: 0 task = less than a day of implementation duration. 1 task = 1-3 man-days of implementation duration. 2 task = 4-6 man-days of implementation duration. 3 task = 7-9 man-days of implementation duration. 4 task = 10-12 man-days of implementation duration. 5 task = 13-15 man-days of implementation duration. 6 task = 16-18 man-days of implementation duration. 7 task = 19-21 man-days of implementation duration. 8 task = 22-24 man-days of implementation duration.

Cycle time is used based on buckets (task counts) and it works fine but I would like to easier the process as much as possible. Is there any suggestion to move towards better and easier estimation techniques?

Improve this question
5
  • If you just say it's about 3 days per task, that's basically saying every work item is the same size, right?
    – Erik
    Jun 25, 2018 at 15:06
  • There is a lot in here I'm confused about. First, what work are you doing that man-days are a helpful unit of measurement? It can be useful, but only on mostly mechanical work that is easily transferrable between people and can be done concurrently. Second, I don't understand what MMF has to do with this. Third, if you are practicing Kanban what are you trying to optimize for. And finally, what are you trying to do with your estimates?
    – Daniel
    Jun 29, 2018 at 2:34
  • Please explain, what is MMF? Is it like MMD? (but about 30 times bigger)
    – ctrl-alt-delor
    Jun 30, 2018 at 9:49
  • Some feature that can be sell to the clients, full working functionality not just piece of it. Something that sales agent can sell.
    – Aram Petrosyan
    Aug 14, 2018 at 22:23
  • We are developing SaaS application. Individual task estimations are needed to form quotes for the clients, example new feature which will take 2 devs 8 days to implement it, transformation it to money. Bulk estimation for the release planning purposes. Kanban is used for it's visualization, WIP limits and process optimization.
    – Aram Petrosyan
    Aug 14, 2018 at 22:24

2 Answers 2

Reset to default
0

By tracking the difference between estimated delivery & actual delivery by item size as well as total items in a rolling average. You'll see the team's forecasting strengths/weaknesses/progression over time. The greater the variation in size among items the more difficult it will be to gather actionable data; consider breaking those big ones down.

Improve this answer
1

Your business will eventually get much better results from measurements and statistical forecasting than by estimates. Using estimates for business purposes has never really worked well or been recommended by even the mainstream agile community. But if the business wants estimates, kanban doesn’t say you aren’t allowed to do so. By all means estimate however you like until you develop the maturity to move to measurements or statistical forecasting. “Better estimation techniques” is a dangerous red herring. Estimates should always be rough, and should be used as part of an approach where rough estimates work. I.e. when a team decides to use relative estimates to plan a sprint in Scrum. But it all depends on what you are doing and why. If cycle time on individual items is interesting I guess people want to know turnaround times on individual service tickets, (rather than e.g. trying to price a software development project). In such a case, surely your actual cycle time measurements are going to be better predictors of future cycle times than estimates? Maybe try both techniques in parallel and show the boss the results of each and he will decide to drop estimation for himself.

Improve this answer
5
  • Statistical forecasting bases on cycle and lead team mainly. In our case cycle time of Task Count = 1 ticket varies from Task Count = 8 ticket, hence it is impossible to use cycle time as a single source of forecasting without having an estimate.
    – Aram Petrosyan
    Jun 27, 2018 at 12:42
  • Let's assume we are not estimating and use statistical forecasting. Without estimates there are ticket completed in 1 day and tickets completed in 30 days, this variance is big enough to fluctuate your predictions and get them to NOTHING. That's why there are suggestions to keep items similarly-sized so that to be able to use statistical forecasting, but we can't keep items similarly sized because we will violate MMF (Minimum Marketable Feature) which is critical for the project. This is our main problem that we keep estimates. Any thoughts?
    – Aram Petrosyan
    Jun 27, 2018 at 12:46
  • 1
    If management aren’t interested in true end-to-end lead time for single items (which would involve dozens of tasks, queueing time, external delays etc) or delivery estimates for larger projects, but just on single task durations then indeed estimation is more appropriate so please use that. Definitely no need to keep things similarly sized. Just like how a scrum team needs to estimate to plan various sized items for a sprint, you probably need to estimate them for your management. Usually kanban is used at higher levels where estimation of single items across single tasks is less useful.
    – Kurt
    Jun 27, 2018 at 12:52
  • Aram, do you need to estimate individual features or your management wants to know when some group of such features will be delivered? If second, and the group contains about 12 items, then you can try statistical forecasting.
    – Anton Nepomnyaschih
    Jun 30, 2018 at 16:14
  • Both needed. First one for quotes for the end clients and the second one for release planning purposes. When you say statistical forecasting do you mean grouping and analyzing average cycle times of various work items such as:? 1. New Features 2. Improvements
    – Aram Petrosyan
    Aug 14, 2018 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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