It’s been some time from the previous chapter of the Kanban Story but it doesn’t mean we’ve stalled. There’s an interesting concept which I keep referring to but only recently realized I’d never really written about it.
The concept is called standard-sized features.
If you read about Kanban you just have to be familiar with the term Minimal Marketable Feature, which is a piece of functionality which is as small as possible, yet sellable to a potential customer. It is a very nice concept and that was exactly what we started with when we were adopting Kanban.
However, after some time we realized that we sacrificed marketability of our features in order to get them similar in size. This change wasn’t really planned. It just seemed more convenient on occasions to split the work that way.
It might be easier for us since we were never orthodox with MMFs. After all how could you possibly marked some architectural changes or rewriting one of integration interfaces from scratch? Anyway that wasn’t a reason to come up with standard-sized features (should I call them SSFs?)
SSFs were born because we needed to prepare some estimates for fixed price projects even though for most of these projects preparing estimates was the only activity we were performing. It is a kind of situation when you don’t really want to invest lots of time yet you still want to come up with some reasonable numbers in case you actually get the project and are expected to deliver it.
In such environment MMFs can be tricky. I can perfectly market a feature which consists like a couple dozen lines of code if it is the right code in the right place. On the other hand for some other features you may need tons of code until finally there is something which can possibly be sold to anyone, assuming that they’re partially crazy and would buy some half-baked functionality.
So yes, MMF can differ vastly in size. And this renders your average measures, like average cycle time, pretty much useless. If variation of cycle time is big so you may deliver it in 2 days but you can also deliver it in 2 months, depending on what kind of MMF it is, you can’t base on average or median. This way if you’re out of luck and get a bunch of huge MMFs you’re also totally screwed.
The answer can be SSF. With standard-sized features you don’t really care what you can market. Actually that’s probably not the case for majority of teams since we rarely directly sell our crap… I mean products. SSFs however allow you to deal neatly with estimation. You can use some simple methods to come up with a number which would go into a formal agreement like instantly, no matter how hard you try to explain a salesman what coarse-grained estimate really means.
Another nice trait of SSF is it helps make flow smoother. If feature’s size differs much you tend to have those big tasks hanging there for a longer time. It makes the team less flexible, as part of the team is dedicated to work on this specific task, and it consumes part of the limit for a longer time which may yield some blockers.
One of arguments against SSFs I heard is it’s pretty hard to learn how to get features standard-sized. Probably if you want to make them all delivered in 9 days sharp it is hard indeed. However you don’t aim for such accuracy. Variation between 6 and 12 days is completely enough. Anyway the surprising thing, at least for me, was we quickly became pretty good in splitting the work into standard-sized chunks of work. It looked like we didn’t even try and got it right, so we just kept doing the good job.
Standard-sized features proved to be valuable so you might consider them as one of options when deciding what exactly you want to have on your sticky notes you put on the Kanban board.
If you liked this story make sure you check the whole Kanban Story series.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
7 comments… add one
Not sure what happened to some of my words there!
@Arran – In terms of getting features more or less similar we go mainly with experience supported with gut feeling. After all we don’t aim to have every story sized identically. We just generally want to have lower variation in vast majority of cases. It does mean that we accept that we can have some exceptions when we build a feature very long, or very short, time and we’re still fine with it.
It’s more about the strategy of splitting features – you don’t start thinking what is minimal piece of functionality you can sell to the client but you think what piece of functionality does make sense and it still fits your standard size.
I was pretty surprised how fast be became pretty consistent at that. It wasn’t that hard.
Hi Pawel,
Is there anything like a “functionality size threshold” for a particular project? is it relative or absolute for a particular software program? For instance, I have this project which is estimated to have in total 3000 lines of code. I am pretty sure that with a project so small, there is a point after which I won’t be able to split it any further into functional constituents. Is there any advice that you would care to give us on this matter? I am simply not very happy with the “gut feeling” answer to this problem ;), perhaps because I can’t rely on extensive industrial experience Cheers
@Lucas – There’s no such thing. If you aren’t happy with following gut feeling or the team isn’t experienced enough to come up with some reasonable sizing my advice would be to start with Minimal Marketable Features (MMF). If you work on a product someone in the team should be able to tell what minimal part of functionality does make sense for a user and voila – you have your MMF. With this approach feature size will probably differ but it isn’t really a big problem most of the time.
The idea of Standard-Sized Feature came when we were pretty experienced with Kanban and we actually came to the point when we saw more value in having features similar in size than in making each feature marketable. It was also the point when we could pretty accurately tell how much time it would take to build the thing.
However it doesn’t mean we were trying to make every single feature to fit exactly our cycle time. We just wanted to avoid order of magnitude, or couple of orders of magnitude, differences so we didn’t have to deal with features which take 3 days or 3 months.
Anyway we switched to that because:
1. We saw value in new approach, e.g. easier planning and estimating.
2. We felt comfortable working this way, e.g. we didn’t struggle chopping functionality the new way.
Otherwise we wouldn’t go that path.
Pawel,
I’ve been following your blog for a while and would love to move toward Kanban for a couple of my teams. In one case, though, we’re using technology that’s not familiar to most of the team (Drupal), so a developer has to do some research/playing around to figure out how/whether a certain module will work for the intended purpose. We hope that those activities eventually lead to marketable features, but sometimes they don’t, and they often take longer than a few days. Any ideas about how to handle this?
thanks!
@Linda – A few of ideas which you may find useful:
* Don’t treat marketability as totally crucial thing. We sometimes add a feature which we know won’t be marketable but we still see some value in building it. In you case just pull your research tasks as any other tasks through the board.
* You may want to add a specific stage to show that specific feature/task is researched and not yet built. We actually did that with our board adding design stage — you can see more in one of my posts on Kanban board.
* If you decide after research that you don’t want to build the actual feature just call it completed and move into done column. You may want to mark it in a specific way so you know it hasn’t been built so you can filter it out when you analyze your cycle time/lead time or you verify what’s really been built.
And one final advice: don’t treat process described on Kanban board as a sacred cow. It should reflect how you work and not the other way round: the way you work should be a result of what you’ve scribbled on the board. If something doesn’t really suit the board decide whether it is just the example, and then treat it like one, or it might be a common situation so you might need to change your board.
@Linda – And, by the way, your question would be a great one to ask on Project Management Stack Exchange. Would love to see it there and you’d probably get some more ideas from other folks as well.