BABOK Technique Summary :10.27 and Agile 7.17

By Carrie Alsvary, CBAP

Below is a summary of BABOK section 7.17 version 3 and Agile Techniques 10.27 from the Agile extension to the BABOK guide version 2.

Technique 10.27 Lessons Learned
Purpose – The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases.
 
Description – A lessons learned session (also known as a retrospective) helps identify either changes to business analysis processes and deliverables or successes that can be incorporated into future work. These techniques can also be beneficial at the close of any milestone within the effort. These sessions can be either formal facilitated meetings with set agendas and meeting roles or informal working sessions as long as they are acceptable to the stakeholders. Celebrations may also be held in a lessons learned session.

 
Elements
Sessions can include a review of:

  • business analysis activities or deliverables,
  • the final solution, service, or product,
  • automation or technology that was introduced or eliminated,
  • impact to organizational processes,
  • performance expectations and results,
  • positive or negative variances,
  • root causes impacting performance results, and
  • recommendations for behavioral approaches.

  
Usage Considerations – Strengths

  • Useful in identifying opportunities or areas of improvement.
  • Assists in building team morale after a difficult period.
  • Reinforces positive experiences and successes.
  • Reduces risks for future actions.
  • Provides tangible value or metrics as a result of the effort.
  • Recognizes strengths or shortcomings with the project structure, methodology, or tools that were used.

 
Usage Considerations – Limitations

  • Honest discussion may not occur if participants try to assign blame during these sessions.
  • Participants may be reluctant to document and discuss problems.
  • Proactive facilitation may be required to ensure that the discussions remain focused on solutions and improvement opportunities.

 
Agile Extension 7.17 – Storyboarding
Purpose – Storyboarding is used to describe a task, scenario, or story in terms of how stakeholders interact with the solution.
Description – Storyboarding is also known as dialogue map, dialogue hierarchy, customer journey, or navigation flow. It is a technique to help with understanding how people will actually use the solution. Storyboarding is used in conjunction with other techniques such as use cases, user stories, and prototyping to detail visually and textually the sequence of activities summing up different user interactions with the solution. This technique is used when formal prototypes may be unnecessary or too expensive.
Storyboarding serves

  • to elicit, elaborate, organize, and validate the requirements,
  • to communicate to stakeholders what needs to be built,
  • to assist in user interface design,
  • to show different variations of the proposed solution,
  • to align stakeholders with the vision of the proposed solution, and
  • as an input to tests.

When used to describe the interaction with a software system, the storyboard shows how screens will look and how they will flow from one to another. When used to describe the business organization, the storyboard shows the interaction with a business process such as back office. Storyboards can be developed as either physical or digital products and can be created in a workshop environment with relevant stakeholders. Storyboards are common and are a form of prototyping.
 
Elements
Scenarios - When planning a solution, business analysis practitioners identify all the possible scenarios for which a customer will interact with the solution. They consider the nuance of each scenario, which steps the customer will take, and what is the desired outcome. The likelihood of the scenario occurring, and the complexity involved in the scenario is also identified. .
Illustrations -  Storyboards are visual illustrations of the solution and how the customer interacts with it. Typical storyboards involve a series of boxes or segments depicting each step in the scenario.
Textual Explanation - To add context to the visual illustrations, textual explanations accompany each box or segment to explain the step as necessary.
Create Storyboard - The steps to creating a storyboard include:

  1. Identifying the main scenarios within the scope of the initiative. This can be derived from use cases, user stories, in a customer visit, or an information gathering session with subject matter experts.
  2. Selecting the scenarios for the storyboard. Not all scenarios require a story board. The most common and most complex scenarios are storyboarded.
  3. Creating illustrations for the storyboards of the selected scenarios.
  4. Enhancing the storyboard illustrations with textual information such as optional interactions, unavailable interactions, further stakeholder requests not associated with the primary scenario, and general notes associated with a specific step. Each storyboard should stand on its own with required explanations.
  5. Validating the storyboard with stakeholders to ensure accuracy and alignment.

 
Usage Considerations – Strengths

  • Can significantly reduce abstractness caused by other techniques such as use cases and user stories.
  • Can be produced quickly and at a very low cost compared to other techniques such as prototypes.
  • The intuitive nature of the storyboard encourages stakeholder participation.

Usage Considerations – Limitations

  • Different look and feel than the final product.
  • Easy to get bogged down on how, rather than why.
  • Easy to miss some significant rules or constraints due to concentration on the visual flow.