We have limits on our Kanban board. This isn’t really a news. Sometimes we abuse them. Since Kanban doesn’t force you to stick to the limits always-and-by-all-means it shouldn’t surprise you much either. However the interesting thing is when, why, how and how often we do it.

I think I should start with stating that our limits are rather loose. It is technically possible to have as many as 15 MMFs in progress across the board. It never happened and it won’t ever happen, but still it is technically feasible. That’s crazy huge workload for 5-person team.

But we happen to have limits like that and it’s not without a reason. If you recall our pseudo-iterations triggered by VCS issues you know we ship our software in packages of few (typically 2 or 3, sometimes 4) features. This means we sometimes move a group of 4 features across the board. For example it happens after deployment when we move features from testing complete to live stage. OK, enough of introduction about our limits.

When do we abuse limits?

It sometimes happens we change content of our deployment package on the fly. For example we have a package of 4 features in testing (either ongoing or completed) and then our crazy product owner (aka me) comes with an idea to add another tiny but super-important and super-urgent feature. Of course we could wait till another pseudo-iteration is deployed but sometimes it just makes more sense to add it to the old package instead of waiting another 13 days for another deployment package.

We also had a painful MMF blocked for long weeks by our subcontractor. This practically reduced our limit in development by 1 for a longer time. It happened once that we decided to break this reduced limit acknowledging the fact we can do nothing more about blocked feature.

Why do we abuse limits?

Two words: common sense. If it is more reasonable to break the limit than to adjust whole work to our board we don’t try to perform some artificial actions just to be compliant with the process.

We aren’t here for the board. The board is here for us.

How do we abuse limits?

First we all discuss the decision. Breaking the limit shouldn’t be treated as a normal thing. It is an extraordinary situation. So we collectively decide whether in this very situation breaking the limit is a better solution or we should rather stick to our constraints.

This serves two purposes: one, we make this decision very consciously and two, we stress that it isn’t a typical and easy-to-accept situation.

It happened once when I found the board with a broken limit with no discussion whatsoever about the fact. I fired two third of the team and burned whole office… Well, maybe not really, but man, I wasn’t happy. I wasn’t happy at all.

How often do we abuse limits?

This is the question you were waiting for, weren’t you? Pretty rarely I’d say – thrice a year. Well, describing it as an average result is a bit of abuse itself since it was our first year with Kanban. But you can see this is an extraordinary situation.

To summarize, limits on our Kanban board aren’t a sacred cow. We break them if it does make sense and we decide it is a better solution than sticking to them at all cost. On the other hand we try to make breaking the limit an uncomfortable situation (you know, all this discussion, talking with each other… yikes) so we aren’t tempted to do this very often.

So far it works pretty well.

Read the rest of the Kanban Story.

A question about starting career in project management is heard pretty often. A question about value of different project management certifications usually follows.

There is a bunch of standard answers for these questions. Apply for junior role in project management. Attend a course. Help your PM in her job. Get a certificate (this or another). Buy and read a stack of books on project management etc.

I have another answer. Actually the answer isn’t exactly mine. I’ve ruthlessly stolen it from Scott Berkun.

Go, run a project.

“How? I mean I’m yet trying to get project management job, remember?”

Pretty much everything which happens around you is a kind of project. If you invite a group of friend for a dinner it is a project. If that doesn’t sound like a real project think bigger. Maybe you can organize vacations for friends?

“Yeah, and what do I learn from such a simple thing?”

Don’t tell me it’s easy – I’m just finalizing sailing trip for 25 people. And, believe me, friends aren’t the best clients you can find around. It requires the same skills you’ll be using once you get your PM job to organize this kind of trip.

“Maybe that’s a nice idea but I don’t have 25 friends.”

That sucks, man. But you definitely have some non-profit organization which would appreciate some help in their projects. And they do have a lot of them. And they’d love your help they’d get for free (non-profit often means non-paying too).

“But, you know, this whole non-profit stiff isn’t really something I’d like to work on.”

Um, you think once you are a project manager you’ll be able to choose projects you like and reject those you don’t. I have a bad news for you. You won’t. You know life isn’t as nice as they told you.

“OK, but how it helps me to learn project management?”

You basically organize a group of people to do what you want. They come to a meeting point. They go to target place where they’re warmly welcomed by your hosts. People know when they can go watch latest World Cup match and when they should bring you a cold beer in exchange for organizing this great trip. Earlier everyone paid you their share of costs so you could have paid for your shelter.

This isn’t much different from project management in real world. You make people doing what you want. They work on a project tasks of your choice. Everyone knows when they’re free to learn new technology and when they should focus of finishing before deadline. Earlier people agreed on plan of splitting tasks and build a schedule etc.

“What about all the formal stuff? I don’t have to create technical specifications when I organize a trip for friends.”

Oh, really? You don’t? That’s interesting… OK, just joking. All the formal stuff will differ among companies so it isn’t so important anyway. Of course you should know what WBS is and understand how to find critical path, but that’s not a rocket science.

What more usually candidates for project management positions lack practical knowledge – lack of understanding of some technical terms isn’t so common.

So go, find a project and run it. After all there aren’t many things which would match your friends thanking you for a great trip and asking whether you’re organizing it next year too. This single thing is worth the whole effort. The funny thing is it works similarly in projects you run at work.

By the way, I’d use the same method to learn leadership.

I like presenting. I just love the fact that every time I deliver the presentation I find something new in there. It’s like having tiny epiphanies while you’re talking to a crowd. And I’m sure I wouldn’t have them if I didn’t overcome my fears and didn’t start speaking publicly.

A thing which hit me last time I was delivering my Kanban Story presentation was how fragile agile is in terms of people who don’t give a damn. In the summary of presentation I make a point that Kanban may not be for your team if you work with undisciplined engineers.

But what I realized while I was talking it is not only about lack of discipline. It’s about care. In Kanban people have to care about Kanban board. They have to move cards as they progress with features. They can’t abuse limits unless it is agreed among the team and team rules allow to. They should think how they could improve the board. They should keep the board up to date.

Why it is so important? Because the board is single most important information radiator in Kanban teams. If contents of Kanban board are random you spread random information about project among the team and outside the team. You pretty much misinform everyone around. And now the important thing:

In Kanban teams anyone can easily abuse Kanban board.

It’s enough someone doesn’t care. He doesn’t care to move cards through the board or put his marker on task he’s working on at the moment or ignore transition criteria or whatever. Suddenly you have random Kanban board and no systemic tools to deal with the issue. People versus Kanban 1:0 at halftime. If you want to know how the match ends, well, you’ll have to read the blog in future since it is a subject for another post.

It’s already half of A4 page and I haven’t really mentioned agile in general. Only Kanban. Kanban this and Kanban that. Don’t I have something else to say? Well, I do, thanks for bearing with me so far.

One of reasons why Kanban is so easily abused by people who don’t give a damn is the fact that Kanban prescribes close to nothing. But enough of K-word. Scrum is more formal. Actually Scrum is pretty formal approach if you ask me. How it deals with the problem?

A bit better. Stand-ups, time-boxing and planning meetings are all practices which help to deal with undisciplined team members. (I wanted to write “engineers” instead of “team members” but I’ve just recalled there are no roles in Scrum besides Scrum Master, Product Owner and Team Member and I prefer not to be killed by some Scrum extremist.) With these practices it is easier to make someone stick to convert folks who don’t care. If you work with Scrum you can’t work without time-boxing while the rest of the team has 2-week long sprints. You are asked the same questions as everyone else during stand-ups. There is more of a stick in Scrum than in Kanban. (Have I just said K-word?)

XP goes even further. Rules are surrounding you everywhere, my poor engineer. It almost tells you how to pee. Not in pairs. fortunately If you work with XP and you don’t give a damn you’re probably already fired.

But let’s face it – how many teams out there use eXtreme Programming religiously? Few. More of them follow just a couple of engineering techniques choosing Scrum as their process base. And even then we have whole variety of Scrumbuts, Scrumbans and Scrumwhatevers.

Average agile approach in real world, if there happen to be something like that, would cover a very limited number of rules. I’d say that there would be less of them than Scrum proposes. And even then rules are often softened or teams choose those which are less painful to adapt.

So we come back to the first point. The fewer constraints (aka enforced practices) we have in place the more easily our process can be abused by people who don’t give a damn. If your method base on a lot of common understanding instead of tons of process documentations and a number of strict rules buying all people in becomes crucial. Having few rules means that you give people power to create and adjust your software development/project management approach.

It also means you give them power to destroy and harm it.

If you like this post you should thank Michal who took the discussion up on Twitter.

I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.

A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.

At the same time in small teams this kind of process looks like complete overkill. In small teams which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.

An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.

You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).

When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.

The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.

Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?

Micro-sized teams

It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.

Frequent priority changes

“Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.

The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.

Maintenance projects

A typical maintenance project routine looks like this:

1. Whenever high-priority bug is submitted fix it as soon as possible
2. Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
3. Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
4. If there are more than single concurrent CR ask project manager about priorities
5. If there are no bugs or CRs do some refactoring or other improvement job

Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?

Multiple small projects

Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”

With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.

Common part

The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.

This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.

If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

What is swarming?

In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

Why, oh why?

Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

Swarming in Kanban, part 1

Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

Swarming in Kanban, part 2

There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

Our story

I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

Read the rest of Kanban Story as well.

Last week we had an internal audit in our team. If you automatically think “ISO 9001” when you hear “internal audit” let me just state it had nothing to do with ISO. We have a few so called quality requirements in the company and every team should follow them but these aren’t anything like ISO procedures.

The reason why I was interested how the audit would go is we work pretty differently than the rest of the organization so quality requirements aren’t really adjusted to our specifics. I was also curious how our non-standard process would look like in comparison to other teams.

I caught a few things which are worth sharing.

Small Features versus Big Features

Our currency for functionality is MMF (Minimal Marketable Feature). MMF itself probably doesn’t tell you much and I know different teams use different sizes for MMFs. In our case average MMF can be coded by a single developer in about a week, so they are pretty small.

On the other hand in other projects typical currency for functionality is requirement which is significantly bigger and, as such, less detailed. I’d say that on average it is few times bigger than MMF.

Where’s the difference? I mean, besides the size itself. One very visible difference is we do significantly less paperwork. With features small enough that they can be easily analyzed and decomposed by product owner, developer and tester we don’t need to write low-level design documents or test cases or user stories. We can spend more time doing the real work instead of creating a pile of documents which tend to become outdated as soon as you hit the save button.

Frequent Deployment versus Not-So-Frequent Deployment

I guess there aren’t many teams which still treat deployment as one-time effort done at the end of project. But still, frequent deployment is a painful thing, especially when developers work in different team than QA engineers and QA engineers work in different team than release managers. An average project isn’t deployed biweekly. Not even close.

On the contrary we deploy, on average, once every 9 days and I mean calendar days here. Of course it didn’t look like that from the very beginning and it cost us a bit to get there. I would say it took us about half a year to gain this pace.

Where’s the difference? I could tell you about time-to-market, but it really depends on project whether you need time-to-market counted in days or months. The cool thing is somewhere else. With such a short cycle time we don’t have a temptation to incur technical debt. We don’t leave unfixed bugs. We just don’t. After all we might have been discussing about a single low priority bug, not a few dozens of them so the fixing cost would be so low that we don’t even start the discussion in the first place. Even if we hit a dead-end redoing the whole darn feature doesn’t take us a couple of months – it’s just a few days so it’s much easier to accept it.

Everyone on the Same Page versus Formalized Process

We’re small team and we’re co-located so we have fairly few communication issues. The process we follow is very simple and, what is even more important, crafted by our team. We all are at the same page.

Most of the teams in the company follow more formalized process. There are different functional teams which are meant to cooperate, there are specific documents expected from each other by people working on projects etc. On the top of that there’s some office politics too and formalized process is used as a weapon.

Where’s the difference? This one was pretty much a surprise for me, but it looks like our process appears as mature and effective even though it isn’t even recorded in any form. We just know what everyone should do. Whenever some obstacle appears on the way people naturally try to help each other as they see and understand what’s happening. And yes, I’m over the top just because no one forced me to write the process description down. On the other hand formalized process is often artificial for other teams who have to follow it and they sometimes focus on being compliant to the process (or fighting with it) instead of building software.

What Does It Mean For You?

I’m not trying to say here you should now automatically cut every feature you work on in half (at least), deploy three times more frequently than you do now and throw every procedure out. It would probably end with chaos, which your managers might have not appreciated.

I’m not trying to say it was easy to get where we are now. It took great people, some experience, a lot of experimenting and enough time to get better at what we started doing. A year ago I would have hard time trying to point how our approach might be better than what you could find in the rest of the company.

And I’m not trying to say you should read these advices in “this over that” manner known from Agile Manifesto. It’s not only our team which is pretty different than average team in the company but a product is also far from standard projects we build in organization so I compare pretty different environments. I wouldn’t even say that every single team in the company would benefit from implementing our approach, although a few of them definitely would.

These are just things I learned while talking with Ola who audited our team (and many other teams in the company). For me these lessons weren’t obvious. I mean connection between frequent deployment and short time-to-market is pretty clear for anyone who understands what “deployment” and “time-to-market” means, but I’ve never really considered that very short production cycle may help to avoid technical debt too.

And if you’re interested what the audit result was, I’d say it was pretty good. I mean, everyone likes to listen to some compliments from time to time, so we may want to ask for another audit soon.

Recently I told you what a screwed way we chose to measure lead time in our team. Unfortunately I’ve also promised to share some insight how we use lead times to get some (hopefully reliable) estimates. So here it goes.

Simplifying things a bit (but only a bit) we measure development and deployment time and call it lead time (and don’t feel bad at all about that). So how do I answer to our customers when they ask me when something will be ready?

That’s pretty easy. If we talk about a single feature and there is no other absolutely top priority task, I take a look at the board to track down a developer who will be first to complete his current task and discuss with him when he expects to finish it. Then I know when we can start working on the new, super-important feature ordered by the client. Then it’s enough to add two weeks (which is our average lead time) and make some effort to look oh, so tired as I’ve just completed such a difficult task of estimation. Oh, I need to tell the customer when they’re going to get the darn feature too, of course.

This however happens pretty rarely. We try to keep our MMFs (Minimal Marketable Features) stick to their name which means they are usually small. This also means that described situations, when client wants just one feature from us, are pretty much non-existent. That’s why you might have noticed I didn’t take into consideration a size of a feature in described scenario. In the real life we usually talk about bigger pieces of functionality. What we do then is we split the scope into small MMFs and then use two magic parameters to get our result.

One of parameters you already know – it is an average lead time. However there’s one more needed. It takes 13 days for the feature to get from the left to the right side of the board, but how many features are on the board at the same time? I took a crystal orb and it told me that on average we have 4,5 MMFs on the board. OK, I actually did a simple analysis of a longer period of time checking our completed MMFs and I got this result, but doesn’t a crystal orb sound so much better?

Now, the trick I call math. On average we can do 4,5 MMFs in 13 days. Since I have, let’s say, 10 features on my plate I have to queue them. If I worked with iterations it would take 2,2 iterations (10/4,5) which basically means 3 iterations. But since we don’t use time-boxing I can use 2,2 and multiply it by 13 days of my lead time and get something about 30 days. Now I don’t start with empty board so I have to add some time to allow my team to finish current tasks. On average it would be half of lead time so we should be ready in, say, 37 days.

And yes, this is rough estimate so I’d probably go with 40 days to avoid being blamed for delivering estimate which looked precise (37 looks very precise) but was just coarse-grained estimate.

That’s basically what I went through before telling my CEO we’re going to complete management site for the product we work on in 3 months. Well, actually I didn’t told him yet, but 3 months there are. No less, no more.

Although this post may look as it was loosely coupled with the Kanban Story it is definitely belongs there. So go, read the whole story.

The other day I had a presentation on Kanban in my company and during Q&A session we were going through the case of one of our teams which, among other problems, has to deal with a few people playing concurrently the role of product owner.

It wasn’t much later when I read Johanna Rothman’s post touching the very same subject. Johanna shares some advice how to deal with environment where there are more product owners than teams.

Smaller teams, shorter iterations and smaller stories, which Johanna prescribes, are all means to the same end: avoid having multiple product owners working with a team and with a product.

Having multiple product owners for a single team and/or single product is just a bad idea. Why? I’ll answer with another question: what do product owners (or product managers – I don’t really give a damn about titles) do all the time? At least when they don’t drink coffee? Well, they make decision about their products. This is important but that can be done in “never-never” iteration. This is urgent but that can wait until the weather in Seattle is better. This is a top priority right now but that should be on the top of the Bottom 100 list (if there was such thing anyway).

Basically it is product owner who tells the team what they should work on right now (even if it doesn’t happen in such a direct way).

Now, imagine there are a couple of these priority-setters around. And they differ on most decisions. Anyway if they agreed on everything one would be um… redundant. Which one is the one the team should follow? Now imagine there are three or four of them and they are randomly landing on team meetings throwing their ideas at developers expecting to see working results right after this iteration. Now imagine one of them is C-level exec. Man, that sucks, doesn’t it?

That’s the basic problem when you introduce more than a single person responsible for setting general priorities for a group. When it happens so, you likely need some kind of an arbiter to enforce consensus when decision-makers around can’t find one by themselves. And the guy becomes a kind of Uber Product Owner who does the same job as simple product owner but on a higher level – deciding which product/project gets highest priority at the moment and overriding decisions of plain product owners when necessary.

Another approach which can solve the problem is splitting product and/or team until you can end up with a few pretty independent streams of work and a single priority setter for each stream. This way each group works on their small chunk of work while you keep your finger crossed to avoid having too many integration issues.

Actually both approaches are two different implementations of the same basic concept. There should be a single product owner/product manager per team and per (part of) product. That’s because having multiple product owners is just a bad idea.

During AgileCE conference I had a discussion with Robert Dempsey about measuring lead time. I never really thought much about the way we count lead time in our team and talk with Robert triggered some doubts.

What We Measure

As you already know on our Kanban board we have backlog, todo queue, several steps describing our development and deployment process and finally done station.

OK, so when do we stamp the starting date for the feature? We do it when the card goes from todo queue into design station, which is the very first column in our development process.

When do we stamp ending date then? You may take your best guess and um… you’ll be wrong. No, not when the sticky note is moved to done column. Actually we mark ending date when a feature makes its way to live column which is third station from the right.

And this is different from what you may have heard from Kanban gurus out there. Don’t blame me, I’ve already told you thought-leaders don’t know it all.

What we measure is time which passes before we start actual work on feature to the moment it goes live.

What We Don’t Measure

What is left behind then? First and the most important thing is the time feature spends in todo queue waiting for some developer to become free and start working on it. If you were trained by the father of Kanban – David Anderson – you’ve probably heard something different but stay with me, I have a good explanation. Or so I guess.

Another thing which is left outside is the last part of our process. There is documentation station where we (surprise, surprise) update documentation. This is done after pushing new version to production.

It looks like we cut something on both ends to make our lead times look better, doesn’t it? Anyway what we gather as lead time doesn’t really describe time which passes from the moment of decision to build the feature to the moment it is done-done. Thus another question arises.

Why, Oh Why?

The way we measure lead time came in natural way but chat with Robert forced me to make some explanation up to justify our practice.

Time Spent in Todo Queue

We left time spent in todo queue out basically because content of this station is changing pretty often. Sometimes feature lives there just for a day or so just to go back to backlog when priorities change. And believe me they do change every now and then. Sometimes a feature stays in todo queue for a longer time as it is always pushed to the second or third place because, well, priorities change.

There is another reason too. The basic reasoning for adding time spent in todo queue to lead time is that you should be able to tell your customer how long it would take from the day 0 (when they tell you they want the feature) to the moment they get it in production. It is pretty rare case when developers are able to start working on a new feature immediately so it is natural that some delay will appear when feature is waiting for a free developer.

I’m not convinced though. Actually very much depends on additional circumstances. The feature the client is asking for may be the only high priority thing to do at the moment but it is pretty unlikely. If the client asks just for one feature lead time will be different than if they asked about a list of ten features. If you have limit of 3 in todo queue you would need to put 7 features in backlog anyway and time they spend in backlog won’t be measured.

If you have a few clients and you need to balance your workload among them it becomes even more complicated since product owner (or whoever is your priority setter) has to decide which feature can be put on the top of the todo queue, which can occupy second or third place and which has to go into backlog.

Basically in any situation but the simplest measuring time spent in todo queue wouldn’t help us much and that’s why we decided to exclude it from lead time.

Time Spent on Documentation

With documentation the situation is a bit different. Documentation isn’t a real part of our product. We create it for our internal reasons – to make life of our sys admin easier and to avoid problems if he was hit by the bus. This means that, from client perspective, our product is complete as soon as it goes live. Even though we have to do some housekeeping later it doesn’t affect our ability to deliver.

Theoretically it might be a problem if documentation phase would be time-consuming and would steal time we’d prefer to spend for something else, namely deployment or testing. However looking at the past in the team it isn’t a problem so we may safely throw documentation out of lead time.

The next thing is using lead time to create some estimates but that’s the subject for another post.

If you liked this post you should like the whole Kanban Story too.