Continuous integration (CI) is a great ‘tool’ for software development. But the best CI tool installation doesn’t mean that your team is practicing CI. The goal of continuously integrating software is to keep the product working at all times so that a broken system can be discovered and fixed quickly.
In order to achieve this goal, tests demonstrate a working system and the team frequently communicates changes.
When a team starts out on CI, the first step is usually to install a tool. Usually someone is really excited about the prospect of working software all the time. He or she installs or writes a tool to help make it happen. Once it’s all up and running this happens:
All failing…
Honestly, it’s a great first step. But the kernel of a healthy continuous integration system is establishing a team protocol and discipline. The difficult part of CI isn’t the tool, it’s the practice.
A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.
As a counter-example to the MMF approach: While working on an XP team, our team decomposed features into super-small stories. That way the customer (product manager) could pick-and choose from the sub-features to create the big feature. The team would present a list of each sub-feature like a grocery bill — each item has a cost. For example, the customer might decide that pagination (presenting a list of information on multiple pages) just isn’t worth it, because “hey, we only have 25 rows of data right now!”
An MMF is different than a typical User Story in Scrum or Extreme Programming. Where multiple User Stories might be coalesced to form a single marketable feature, MMFs are a little bit bigger. Often, there is a release after each MMF is complete.
An MMF doesn’t decompose down into smaller sub-feature, but it is big enough to launch on its own.
A MMF can be represented as a User Story — a short, one-sentence description.
The format of a user story is:
As a [some user],
I want [to do something],
so that [I can achieve some goal]
But in contrast to how a User Story is typically used, the team would not break down the User Story into smaller User Stories when using MMFs. Think of it this way: *Gather up all the stories that share the same so that clause — that’s your MMF*.

A team I’m working with has switched from Scrum to Kanban to manage their development efforts. As a result, the team doesn’t have regularly scheduled planning meetings to create a task-driven plan for the upcoming iteration time box.
So does Kanban development have no planning meetings? No! The team self-organizes meetings around a single feature rather than a specific period of time.
Recent Comments