BABOK 10.28 Metrics and KPIs and Agile 7.18 Story Decomposition

by Julie Ramsey

Technique 10.28 – Metrics and Key Performance Indicators (KPIs)
Purpose – measures performance of solutions, their components and other items of interest to stakeholders.
 
Description – a metric measures progress as a numeric indicator.  It shows how close an organization is to reaching a goal or objective.  Key performance indicators (KPIs) specifically measure progress for strategic goals and objectives.  Metrics and KPIs are shared with stakeholders in specific formats and intervals which is known as reporting.
 
Metrics and reporting are inputs to monitoring and evaluation.  Monitoring shows how well a solution was implemented through comparison of data against expected results.  The solution is then assessed to verify how well objectives were met and identify improvements which is known as evaluation.
 
Elements
Indicators – show the results of one or more measures in a table or graph format. Good indicators are clear, relevant, economical, adequate, quantifiable, trustworthy and credible.  The business analyst should consider source, collection method, collector, cost and frequency when establishing an indicator.
Metrics – quantifiable levels of indicators taken at a point in time.  Metrics can be a point, threshold or range.
Structure – setting up a monitoring and evaluation system includes a process for data collection, data analysis and reporting as well as collection of baseline data.  To assess the quality of indicators and their metrics, consider reliability, validity and timeliness.
Reporting – compares baseline, current and target metrics.  Trends are generally more credible than absolute figures and visual presentations tend to be more effective.
 
Usage Considerations – Strengths

  • a monitoring and evaluation system helps stakeholders understand the value of a solution
  • indicators, metrics and reporting drive organizational alignment

 
Usage Considerations – Limitations

  • gathering too much data can result in distraction from other responsibilities and increased expenses
  • metrics tied to performance can lead to focus on those areas and neglect of other activities

Technique 7.18 – Story Decomposition
Purpose – represents the requirements of a solution with enough detail and aligned to desired outcomes.
 
Description – Offers a structure to define the elements of requirements at smaller levels of granularity.  Story decomposition starts at the broadest system level and drills down to individual stories with specific acceptance criteria.  A common approach is called “breadth-before-depth”.  Product goals are decomposed into components which are decomposed into stories.  In agile initiatives, this process is incremental with an understanding that stories and requirements will evolve over time.  Business analysts use collaboration, facilitations and communication to gain approval of the minimum detail required to develop/deliver the solution.
 
Elements
Solution Goals – highest level of requirements representing what’s driving the initiative.
MMF/Component – Minimal marketable features or components are value add groupings of functionality for a solution. 
Story – this could be a user story, job story or use case that will be part of the solution.
Acceptance Criteria – used to validate the story and can be written as a list, specification or acceptance test.
 
Usage Considerations – Strengths

  • keeps focus on the big picture
  • assists with release level planning and gives visibility into development of the solution

 
Usage Considerations – Limitations

  • may be tempting to treat as gathering detailed requirements upfront so the business analyst must keep focus on just enough and just in time
  • focus must be on customer value rather than process, architecture or procedure