The stated cycle times (in green) are averages that we measure and keep updated. Orange icons are the buffers in our system to ensure smooth flow and to have independent cadences for business to figure out WHAT we should build and development to BUILD it. Please keep in mind that all our developers are part timers (we do agile and lean consulting besides the development).
MMF stands for a Minimum Marketable Feature that is the smallest possible set of functionality that, by itself, has value in the marketplace. Read more about MMFs from Karl's blog.
DWT stands for Disneyland Wait Time. It is the expected wait time to get full backlog (7 MMF s) DONE, which is good information for our Product Owner.
Our product development has several inputs:
- we try to meet users (Finnish) in a brainstorming session every month in our office
- we have done feature voting, surveys and get-together with our community
- we try to engage discussions with our users via Facebook group, monthly newsletter (Finnish) and Twitter
- we are lucky enough to get feedback from our users via email
- we dig into our metrics and business reports (AARRR etc.) to figure our what works (we also look for features that are just waste)
- we look into competition and new partnerships
- we try to come up with new bright ideas for our product
Figuring out the Minimum Marketable Features (MMFs)
Once the themes are selected, we work on those until we have MMFs to serve the theme in best possible way. We argue the business value of each MMF and figure out the T-shirt size of each MMF (have been thinking of using Story Maps, Kano model etc. here. So far it has been just list of MMFs each having relative value that is based on our business value model, this is definitely an area that we sould also improve) and finally our Product owner chooses up to seven items to "product backlog" (WIP limit 7), which is actually just queue of NOT-STARTED MMFs, not necessarily in prioritized order as real product backlog would be. Why you might ask.. because developers cannot pull items from there as they are not READY yet.
From NOT-STARTED to DONE aka when are we READY and when are we DONE?
Product owner prioritizes the MMFs and starts working together with the team to get top items READY.
So what's our definition for READY?
- No immediate blocker for developing the MMF
- If MMF has impact on language content the content is available. It might not be final.
- If MMF has impact on look & feel the content is available (GUI layouts, graphics..). It might not be final.
- If MMF has impact on emails sent to the users the email templates are available. They might not be final.
- If MMF has impact on reports the expected changes are communicated.
- If MMF has impact on third party services/integrations the expected changes are listed. List might (and usually is not) final.
What does it mean that MMF is DONE according our definition of DONE?
- MMF can be released
- code has unit tests and automated acceptance tests that execute successfully
- code passes tests in CI environment
- code is refactored and the design is simple
- code passes automated QA checks (checkstyle, pmd/cpd & whatnot)
- new feature is documented (if applicable, sometimes for third parties)
- peer review is done (if applicable, sometimes for critical paths)
Our current Kanban board
The bright blue boxes (SMART goals etc.) are kind of rules that we have for items that belong to a column.
You might be wondering how we divide the labor between "biz and tech". The following illustration demonstrates our Problem and Solution "teams":
They are heavily overlapping due that we are doing tons of collaboration in each process step.
Have an idea to share? Please also comment for suggesting a topic for next post - I was thinking of showing what exactly is our MMF (internals) or maybe how we work on GUI as it seems to be hot topic in agile community right now.