Technique Summary: BABOK 10.22 and Agile 7.13

By Julie Ramsey

Below is a summary of section 10.22- Functional Decomposition from BABOK® version 3 and Agile Technique 7.13 – Relative Estimation from the Agile extension to the BABOK v2.

Technique 10.22 – Functional Decomposition
Purpose – Functional Decomposition manages complexity and reduces uncertainty by breaking processes into simpler parts for independent analysis.
Description – Functional Decomposition is used to consider complex systems as related functions or components allowing for ease of analysis.  The simplification into sub-components allows for scaling, tracking and measurement of work effort.  In this way the Business Analyst can evaluate the success of each part.
Each sub-component will have only one parent in the functional hierarchy.  The Functional Decomposition may be displayed as a branching hierarchy diagram.
Decomposition Objectives – The objectives drive the process to decompose and define what, how and how deeply to decompose.  Objectives may include measuring and managing, designing, analyzing, estimating and forecasting, reusing, optimization, substitution and encapsulation.
Subjects of Decomposition – Functional Decomposition may apply to a variety of subjects including business outcomes, work to be done, business process, function, business unit, products and services and decisions.
Level of Decomposition – Functional Decomposition should provide just enough detail to utilize the results in the execution of other tasks.  The appropriate level will meet the analysis objectives.
Representation of Decomposition Results – This element consists of a variety of models, maps and diagrams. These visual representations validate and verify the results so they may be used to solve other tasks.  Some examples of these representations are Use Case Diagrams, Decision Trees, Mind Maps and Flow Diagrams.
Usage Considerations – Strengths

  • Breaks complex problems into simpler parts for ease of analysis.
  • Results in shared understanding of complex issues.
  • Measurement and estimation are simpler to achieve resulting in inputs to decisions on actions and scope.

Usage Considerations – Limitations

  • May require in depth knowledge of a subject and extensive collaboration with stakeholders.
  • Complex subjects could have multiple decompositions and exploring all of them would be time consuming.However, exploring only one could preclude opportunities and limit the solution.
  • Systems may not be easily represented by simple hierarchical relationships due to complex interactions between the components.

Technique 7.13 – Relative Estimation
Purpose – Relative Estimation helps make predictions about completing future work using experience, knowledge, complexity, size and uncertainty.
Description – Estimation is progressive and aligned with iterations in an agile environment.  Early estimates are less accurate than later estimates determined closer to delivery.  This is because new information is discovered about the components, complexity and characteristics of the work as agile promotes continuous feedback and learning. 
Estimates are used to guide decision making and provide value to stakeholders in determining cost and effort, establishing priority and committing to a schedule.
Agile business analysts utilize traditional estimation in addition to Relative Estimation.  As teams develop stories to define user needs the stories are given a numeric value or story point value.  Relative Estimation considers story points from past stories and team experience, knowledge, complexity, size and uncertainty to provide a point size relative to these past stories.
The total number of story points delivered in an iteration is considered a team’s velocity and over time the team will gain an understanding of their typical velocity.  This understanding informs the teams estimating and decisions about work committed in future iterations.
ElementsBusiness analysts begin with the following items when preparing to estimate story points:

  • Order of magnitude
  • Fixed iteration
  • Estimation by the team of time needed for a group of various sized stories

Planning Poker – Once the team has a shared understanding of a story, each member chooses a number to represent the work.  All the numbers are revealed, and discussion takes place when there are significant differences to uncover assumed knowledge.  Ultimately, through conversation the team comes to an agreement on a single number.
Silent Sizing – This approach requires physical cards and a space to line them up.  Each team member selects a card and places it in the line with the goal of arranging cards from smallest to largest effort.  Once all cards are placed, the team determines breaking points to group items of similar size.  Each group is then assigned a number using a scale such as Fibonacci.  Then all cards in the group take that same number.
Usage Considerations – Strengths

  • Simple method that is very adaptive and increases in accuracy over iterations.
  • Collaborative and reliant upon teamwork resulting in positive impact to the team.

Usage Considerations – Limitations

  • Since they rely on comparison with previous estimates, if new work is significantly different, the accuracy of estimates will be impacted.
  • Estimates are specific to team understanding and do not translate across teams.
  • Stakeholders may focus on estimates which represent output rather than value delivered representing outcomes.