Tag Archives: scrum

Low Fidelity vs High Fidelity

9 Mar

Low fidelity assets are frequently employed on Agile projects. An example of a low fidelity asset is the production of basic wireframes/”back of the napkin” designs:

Screen Shot 2013-03-09 at 22.21.34

The advantage low fidelity designs is that they encourage feedback and corresponding design iterations – without the waste/overhead involved in high fidelity assets.

In terms of the Business Analyst role on Agile projects – low fidelity assets may include:

  • User stories
  • High level requirements (basic specification)
  • High level acceptance criteria (basic user acceptance conditions)

What are the advantages of the Business Analyst employing the above mentioned low fidelity assets:

  • They encourage a focus on the essential behavior of the system (MOSCOW must haves). This ensures the Minimum Viable Product (MVP) is documented early in the project lifecycle.
  • Facilitates communication across a project. Low fidelity assets encourage feedback – they are much easier to present and convey than a 30 page BRD.
  • Mitigates the risk of mistakes entering into detailed requirement specifications – assumptions can be identified earlier on.
  • Descriptive vs prescriptive. The focus is on the high level functionality – this means that the technical solution is less constrained by non-essential elements of the product specification.
  • Easily produced and maintainable – changes can be made quickly and with minimum effort. This sits well in the Agile world.
  • Stand-alone pieces of work (features) can be identified – this enables backlog prioritization.
  • Fidelity (i.e. detail) is added through participative iterations – documentation evolves through collaboration into a steady state.
Advertisements

Product Owners vs Business Analysts – MOSTly different roles?

14 Feb

The MOST acronym (Mission, Objectives, Strategy, Tactics) can be used to describe the main differences between the Product Owner and Business Analyst roles on a project.

Mission

  • This is the vision statement for the product. It should be concise and value driven.
  • This will provide answers to the following questions: What is the intention and long term direction of the product? Who is the user-base/target market? What is the business benefit?
  • Example: “We want to deliver the most popular Sports app in the World – with unparalleled journalist content”
  • Responsibility of the Product Owner.

Objectives

  • These are derived from the product mission. These are targets that will translate the product mission into reality.
  • These will provide answers to the following questions: What goals will lead us to achieve our mission? What will need to be created? What will need to be changed? What will need to be acquired?
  • Example: “We need to deliver live video streaming in the iOS app
  • Responsibility of the Business Analyst.

Strategy

  • This is a description of how success will be achieved. This should describe the features and their prioritisation.
  • This will provide answers to the following questions: How will the product scope be delivered across iterations? What is the Minimum Viable Product for release 1.0/launch? Which features are nice-to-haves?
  • Example: “Pundit analysis, live video & match statistics are required for the first release – personalisation will be delivered in the second release of the app” 
  • Responsibility of the Product Owner.

Tactics

  • These are derived from the product strategy. These are the deliverables that will be provided by the development team.
  • These will provide answers to the following questions: How can we achieve tangible benefits in the next Sprints? What tasks need to be completed? How can work be grouped together logically & in terms of delivery?
  • Example: “Provide live streaming of our CMS videos using Media Player”
  • Responsibility of the Business Analyst.

Summary

Within MOST there are 2 definition activities (Mission and Objectives) and 2 planning activities (Strategy and Tactics).

  • The Mission (high level product definition) is done by the Product Owner.
  • The Objectives (detailed product definition) is done by the Business Analyst.
  • The Strategy (high level product planning) is done by the Product Owner.
  • The Tactics (detailed product planning) is done by the Business Analyst.