Minimum Marketable Features: An Agile Essential

#SridharPeddisetty #Agile #MMF #Strategy #Project #MinimumMarketableFeatures #Management #BestPractices #ProcessImprovement  

"Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the development teams must be ready to adapt"

Introduction

Organizations no longer compete on product or service but they compete on experience of faster to market with quality results. It is an organization's ability to learn and translate that learning into action rapidly, which gives it the ultimate competitive advantage. More often than not, it’s seen that most organizations focus on delivering the software and not paying enough attention to the value the software brings to the business. 

What is a Minimum Marketable Feature (MMF)?

A Minimum Marketable Feature (MMF) is the smallest set of functionality that can be delivered, which has value to both the organization delivering it and the end customer using it. MMF is characterized by its three attributes: Minimum, Marketable and Feature.

• Minimum attribute represents the smallest set whether a feature or feature set, which is key for faster time to market 
• Marketable attribute represents the selling of the significant value to the end customer and to the delivering organization 
• Feature attribute represents the perceived value by the end customer and delivering organization. Value may include brand recognition, competitive advantage, revenue generation, cost savings or enhanced customer loyalty.  

How MMF is essential for being Agile?

Agile is an iteratively incremental SDLC methodology in which requirements and solutions evolve through communication and collaboration between self-organizing and cross-functional teams. Agile promotes ‘building the right thing’ through 

• Customer involvement, 
• Adaptive planning, 
• Evolutionary development, 
• Early delivery, 
• Continuous improvement and 
• Encourages rapid & flexible response to change 

in delivering high quality product or service. MMF provides an essential tool to effectively decompose customer needs into finer grain features, which can be delivered more rapidly than waiting for large scale features to be complete. Using the concepts of MMF, decompose the epics into smaller sets of user stories that provide value to end users in shorter development cycles. In Agile SDLC, it’s during the product backlog grooming when the value of requirements or features can be quantified based on how these requirements contribute to the business objectives. During the grooming, using INVEST model to define a user story or MoSCoW for prioritization, various models or methods could be applied that helps to identify the most important features to implement or identifies the MMFs. A release could then be the collection of MMFs, which can be delivered together within the time frame.

Summary

Product innovation is tied to change and often the need for change appears midstream in a project so decomposing the requirements into Minimum Marketable Features (MMF) helps have the edge while improving the time to market. One essential advantage of MMF is the ability to make changes during development without being too disruptive. In other words, MMF helps in adjusting product requirements during development in response to customer feedback. Jim Shore in his Phase Releases article had shared how to use phased delivery to increase project value:

• Group functionality into MMFs that can be released individually.
• Create a release plan that deploys high-value features first.
• Have the entire team focus on one releasable feature at a time.
• Use continuous design to spread out investment in technical infrastructure.
• Deploy releases as soon as possible.

Previous posts you might be interested in:

• Empower Your Team To Own Responsibilities 
• 5 Reasons To Let Your Team Struggle Today
• Trust Your Team But Make Sure To Verify

Minimum Marketable Features: An Agile Essential was originally published under Prokarma blog on Oct 23rd 2015

Metrics For Maximizing Productivity In Kanban SDLC

#SridharPeddisetty #Agile #Kanban #SDLC #Productivity #BestPractices #Metrics #EngagementManagement

“Measure what is measurable and make measurable what is not so” –Galileo

In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban. In this post, we will look at the metrics for identifying bottlenecks while using Kanban as the software development lifecycle (SDLC) methodology. With experience and motivation to improve quality comes working out the right metrics, which measures areas of continuous improvements. In my earlier post 10 Ground Rules on the Right Metrics for Your Business, I had shared some rules on selecting the right metrics that is tied to the desired business outcomes. As summarized in the blog post, data collection, analysis & management is most often cost and labour intensive, so its important to always weigh in against the benefit derived from the selected metric.

One important principle of Kanban is to maximize productivity by optimizing the flow of work and managing work in progress (WIP) by removing bottlenecks. Before selecting the metrics, we need to assess what metrics is needed and then plan on using the processes and tools, which will provide the data for quantification in a shape and form that will allow us to measure. Presently Organizations are competing to provide faster value to their customers, which is effectively done by sizing and decomposing the requirements into minimal marketable features (MMF).

In Kanban, we can have have the Kanban board visualizing the WIP for states and swim-lanes. States could represent the following phases a user story (feature) or defect goes through the development lifecycle

• Product Backlog (Requirements)
• Defined (Analyzed) 
• In Progress (Development & Testing)
• Completed
• Accepted  

while the swim-lanes could represent WIP for 

• Expedite (Priority) user stories or
• Defects (Severity 1/2) or
• Different functional groups such as
  • Architecture,
  • UI/UX Designers,
  • Business Analysts / System Analysts, 
  • Development 
  • Operations
  • DevOps
  • QA
  • Technical Writers
  • others  

In some cases, Kanban board can represent one swim-lane for both expedite and non-expedite user stories or defects while just visualizing states.

Below is a sample ‘Cumulative Mean Lag Time’ metrics, which is measuring the time spent by a user story (USxxxx) or Defect (DExxx) both expedite or non-expedite in each of the following state

• Requested,
• Defined,
• In Progress,
• Peer Review,
• In QA, 
• In UAT and
• On Hold

From the metrics we can derive following information including identifying bottlenecks and areas of continuous improvement

• Expedite user stories (US7000 & US7674) are obviously prioritized by the team as the time spent in each state was short comparatively, thus faster overall cycle time. Information can be derived from the chart if the expedite items are distracting the team in effecting their WIP items by looking at the mean lag time an item is spending in each of ‘Defined’ or ‘In Progress’ or ‘On Hold’ states.  
• User story ‘US7626’ (second chart) was analyzed, developed, peer reviewed and tested in a short span (~2 calendar days) but spent ~9 calendar days in user acceptance test (UAT) state. One reason for this could be that the user story was not in the priority list for the stakeholders to be released or the priority lowered after the work started. As an opportunity for continuous improvement, we can look at the option where there is an opportunity to reprioritize the user story before the team starts the work.  
• User story ‘US7322’ (first chart) spent a lot of time (~25 calendar days) in ‘Requested’ state and then some time in ‘On Hold’ state (~12 calendar days).  As an opportunity for continuous improvement, we can work with stakeholders to make sure that we are getting the right requirements and acceptance criteria for the user story along with prioritization. The total cycle time for this user story could be also more because of the complexity and/or dependencies on the other integration deliverables. In either case, metrics shows the bottlenecks and provides an opportunity to optimize work flow for future such occurrences. 
• Above metrics also gives the overall cycle time for different sized user stories and defects, which helps in predicting for future work and ability to give a better commitment for the stakeholders 

Summary

User Story is like a fish, the longer its sits on the shelf, the less desirable it becomes. Use relevant metrics to measure lead time in each of the Kanban columns (states), which helps to identify the bottlenecks and to improve planning and forecasting. 

I will be sharing case studies, process improvements and best practices specific for Kanban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

Metrics For Maximizing Productivity In Kanban SDLC was originally posted under Prokarma Blog on Sep 8th 2015