× This site is under continuous improvement. Please help us by providing comments here.

Agile: Discovery

The Discovery phase establishes the business justification for the system and lays the framework for implementation or acquisition. During this phase, a project team explores the system requirements further through interaction with end users and selects a specialized team to produce a Minimal Viable Product (MVP) in the form of a prototype, demo, or mock-up. The MVP is used to gather feedback from end users and, ultimately, to evaluate whether to proceed to the Development phase.

The two key steps of the Discovery phase are described in further detail below.

1. Define the Product Vision

Defining the need from the perspective of both the business and users of the system.

Before development can begin, Product Owners must justify the need for the system they will be building. That justification should begin with an understanding of user needs. System goals should be framed in those terms. By employing user-centered design methods, such as user interviews, usability tests, usage data analysis and task and business process analysis, among many others, a project team ensures that priorities are set based on the needs of those whom the system serves. This information is documented in a high-level Product Vision which establishes initial project scope and expected outcomes. The Product Vision also drives initial resource and budget estimation. A Product Vision is not a detailed set of instructions; it is a simple statement of intent and desired outcomes.

As part of the visioning process, the project team may develop several key deliverables:

Deliverables

  • Team Process Agreement: Defines members and roles for a project team. Defines Standard Operating Procedures (SOPs) for how team members should work together.
  • Product Vision Statement: Defines the problem to be solved, users to be served, and rough scope and time frame details.
  • User Story Map: A tool for a project team to understand the complete vision for a system. It outlines the features that must be built in order to allow users to accomplish critical tasks using the system and begins to prioritize them according to user and business priorities.
    Learn how to build one: http://jpattonassociates.com/the-new-backlog/
  • Epics: From a user story map, a project team is able to extract epics and user stories, which are placed in a product backlog until it’s time to build them based on the priorities set by the Product Owner. Epics are user stories whose scopes are so large as to make them difficult to complete in a single iteration or accurately estimate the level of effort to deliver; they are likely to be progressively refined into a set of smaller user stories at the appropriate time. There are several types of epics:
    • Business Epics: Identifies functional user stories that describe the business need that the software will fulfill, which helps the development team be more realistic in assessing the resources required to build the release and user acceptance tests.
    • Architectural Epics: Identifies the cross-cutting technology initiatives that are necessary to evolve portfolio solutions to support current and future business needs.
    • Security Epics: Security-focused user stories that describe certain types of malicious behaviors to prevent so that the business need (software) being developed is robust, reliable and secure.
  • User Stories: User stories represent epics broken down in to manageable components that may be built in an iteration. They are typically descriptions consisting of one or more sentences in the everyday jargon of the end user that capture what a user does or needs to do as part of his or her job function).
  • Portfolio Backlog: The highest-level backlog in this Agile framework, the portfolio backlog serves as a holding stage for business, architectural and security epics that have been prioritized and await implementation. Items in this repository will eventually become part of the program backlog.

2. Minimum Viable Product (MVP) Planning & Development

The smallest piece of a system that still delivers value.

Once the Product Owner and identified pilot team have worked to decompose the product vision into a story map, they should next define the most critical set of functionality to build to prove the value of the system, based on user research discoveries. This allows the sequencing of work into iterations that focus on quickly delivering a Minimum Viable Product (MVP). In order to achieve an MVP, the team creates a backlog of user stories that are required to meet that goal. During this phase, teams are encouraged to explore the more difficult pieces of functionality to better understand relevant risk moving forward. The outcome of this effort will be a prototype, demo or set of mock-ups to be used for validating with end users and securing approval for development.

Deliverables

  • Program Backlog: The repository for all upcoming epics and user stories to be included in the MVP.
  • Proof of Concept: A functional representation of the MVP that may be used to secure stakeholder approval and funding to proceed with a project.

Leave a comment

Your email address will not be published. Required fields are marked *