Technique Summary: BABOK 10.18 and Agile 7.10

By Julie Ramsey

Below is a summary of section 10.18- Document Analysis from BABOK® version 3 and Agile Techniques 7.10 Product Roadmad from the Agile extension to the BABOK v2.

Technique 10.18 – Document Analysis
Purpose – Document analysis is a technique to elicit information by methodically reviewing material describing the business environment or existing organizational assets.
 
Description – Document analysis can result in background information for understanding the context of a business need or validating how existing solutions are currently implemented.  Materials such as marketing studies, industry guidelines, company memos and organizational charts may be included in the research.  In the case where there is a current solution, business rules, technical documentation, training documentation, problem reports, previous requirements documentation and procedure manuals may also be reviewed.  These materials may shed light on how and why the current solution was implemented. Document analysis can be used to validate findings from other elicitation techniques as well.
 
Elements
Preparation – The business analyst should consider if the content of a document is relevant, current and credible.  It’s also important to think about how easily the content can be explained to stakeholders.
Document Review and Analysis – During the review, the business analyst will take notes for each document.  The notes may be recorded in a chart including topic, type, source, verbatim details, summarized critique and follow up items.  Then the business analyst will look for conflicting or duplicated notes.  Finally, gaps in the information will be identified to determine if further research is needed.
Record Findings – Before presenting, the business analyst may consider if visual aids would be useful in helping explain the findings.
 
Usage Considerations – Strengths

  • Existing materials may be used for document analysis
  • Original sources may identify current versus changed information or processes
  • Results of document analysis may be compared with results from other elicitation techniques to validate information gathered
  • Findings may be presented using visual aids such as graphs or process flows to better explain information

 
Usage Considerations – Limitations

  • Existing materials may be invalid or out of date
  • Authors of original sources may not be available to answer questions
  • This technique is most useful to review documents about current state rather than future solutions
  • Document analysis can be very time consuming and lead to information overload

Technique 7.10 – Product Roadmap
Purpose – A Product Roadmap communicates direction towards the vision for a solution and measures progress toward that vision based on the desired outcome of the stakeholders.
 
Description – This strategic plan describes how the product will grow and how it aligns to stakeholders’ needs.  It can also be used in acquiring a budget for the product.  Product roadmaps include features and requirements and show the path for delivery over time.
 
Focus on the product, features and value to be delivered aligns product roadmaps with the agile desire for working solutions over comprehensive documentation.  This visual technique enables iterative delivery by showing the features maturity generally broken down by quarter. 
 
Elements
Defined Vision and Strategy – The vision clearly defines what is included in the solution and the goal to be achieved.  In addition, to defining the vision, the roadmap articulates how the vision will be achieved.
Defined Desired Outcomes – Stakeholder outcomes are clearly articulated so the delivery team can create a working solution that will add value.
Product Management Team – The Product Owner leads the small product management team that maintains the product roadmap.  It must be kept up to date with current priorities and goals. 
Themes – Themes are found in the product roadmap representing the collection of requirements, features or stories.
High-level Requirements – The high-level requirements found in the product roadmap should deliver value toward the vision and goals of the product.  Each high-level requirement is representative of a group of requirements or stories.
 
Usage Considerations – Strengths

  • Visible and easily accessible to stakeholders
  • Presents one unified view of the solution
  • May have multiple views to accommodate varying audiences such as executives, the solution team, or external customers

 
Usage Considerations – Limitations

  • Ineffective if the organization frequently changes its vision or outcomes desired
  • Can be misused for predicting completion dates or hitting milestones
  • May be time-consuming to keep up if there is too much detail or too many views are needed