Blog‎ > ‎2. Agile‎ > ‎


Product Development Lifecycle

Product development goes through the following lifecycle typically
Product Development Lifecycle in Agile


Product Owner creates the Vision for the product. The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision entails carefully answering the following questions:

  • Who is going to buy the product? Who is the target customer? 

  • Which customer needs will the product address? 

  • Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? 

  • How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points? 

  • What is the target timeframe and budget to develop and launch the product?

Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.

Creating the Product Vision

Since the Product Owner is responsible for the success of the product and its return on investment (ROI), he or she should lead the vision-creation activities through close collaboration with the team. For innovative projects, this team may include business and technical people; for instance, marketers, product and user interface designers, and developers. The more innovative and complex the product is, the more important the vision is and the more effort is required to create it. For new-product development projects and major product updates, market research and prototyping activities are usually carried out. Since it may take several weeks or even months to compile the relevant information in this case, running one or more sprints is the best way to carry out the necessary work. Contrast this with a small product update or a maintenance release where creating the vision may only take a few hours or days.

The Heart of the Product Vision

At the heart of the product vision is the description of the selected customer needs and the necessary product attributes meeting those needs. To arrive at this vision, we first select our target customers and then the relevant customer needs, thereby deciding which market or market segment we are going to address. Then we identify the product attributes, those critical high-level requirements the product must fulfill to satisfy the needs.

Product attributes typically comprise both nonfunctional and functional requirements. Nonfunctional requirements include performance, robustness, and usability requirements. Functional requirements describe specific product functions or features, for instance making a call or sending an email. The product attributes serve as a guide for the team; they constrain the solution space – the set of all possible solutions.

Describing product attributes at the right level of detail is a balancing act that requires close collaboration between the Product Owner and the team. Under-specifying attributes causes a lack of guidance and direction. Over-specifying product attributes results in making decisions earlier than necessary and negatively impacts the team’s creativity. The techniques useful to describe attributes include personas and scenarios, use cases, and user stories.

Desirable Qualities of Vision

Like any important goal, a good vision equally appeals to our intellect and to our emotions. It should motivate and inspire people. The product vision should be clear and stable; broad and engaging; and short and sweet.

  1. Clear and Stable

The product vision must be clear and easy to understand to create alignment and a common purpose, and to avoid misinterpretation and confusion The English term vision is derived from Latin visio, which translates to “seeing, view, notion, idea.” The product vision should hence allow us to see the future product. The vision should not be fuzzy or hazy.

Vision changes, particularly with regards to customer needs and critical attributes, can cause confusion, de-motivation, and project failure. Small adjustments are usually fine, as long as the product’s value proposition stays the same.

  1. Broad and Engaging

The product vision should describe a broad and engaging goal: a goal that guides the development effort but leaves enough room for creativity; a goal that engages and inspires people, fosters creativity, and generates buy-in.

  1. Brief and Concise

The product vision should be brief and concise (Pichler 2008). It should contain only information critical to the success of the product. The product vision is, therefore, not a feature list and should not provide unnecessary detail.

The Elevator Test

The classic way to validate the product vision is to answer the elevator test: “Can you explain your product in the time it takes to ride up in an elevator?” Moore (2006, p. 152). Passing this test ensures that your product vision is clear, engaging, and brief (assuming we ride up a building with the right height and don’t get stuck). Notice that the elevator test does not tell us if we have selected the right customer needs and the right product attributes; only early customer feedback can do that.

An effective product vision guides the Scrum team and aligns stakeholders and customers. Spending time and money on vision creation is a worthwhile investment. As Robert G. Cooper notes: “Too many new-product projects move from idea stage right into development with little or no up-front homework. The results of this ‘ready, fire, aim’ approach are usually disastrous. Solid pre-development homework drives up new-product success rates significantly and is strongly related to financial performance.” (Cooper 2000, p. 3) This does not mean procrastinating the start of development, using an upstream waterfall process that creates a mighty product concept or employing a separate project. The trick is to spend as little time as possible but as much as required; to use Scrum to create the vision; and to ensure that as many of the team members involved in the vision creation as possible also transform it into the actual product.

Agile Charter – The first step in identifying what customer needs

A Chartering is a process of formally bringing a Agile project into existence. It formally authorizes the team to start working on the project. This process generally occurs in the performing organization. A Chartering session helps the team understanding the big picture. Having this understanding helps the team to take important decisions on the project. Since Agile teams rely a lot on self-organization, it is all the more important for the team to know the big-picture. This way, the team will build confidence and customer will trust them to organize and deliver.

Agile Charter answers the following questions about the project

  • What is the project all about

  • Why are we building this product?

  • When will it start and when will it end?

  • Who is the sponsor and what are the approximate funds for the project?

  • How will it be undertaken (high level approach)?

  • How do we know if it is successful?

  • Who is the Project Community? (team, customers, users)

Product Roadmap

A Roadmap is a forward looking proposal of the direction the product should take in the future. It could be a collection of features or themes that could form the main areas of focus for the next few months. Normally a roadmap may be defined for no more than 2 years into the future. Obviously, the Roadmap is a evolving artifact. As we know more about the product, the market it serves and our ability to implement the features.

The Roadmap may change, however, its essential to have a roadmap since it provides a direction and understanding of the strategic direction for a product. It also enables to communicate with customers and stakeholder about what they are expected to see in the future. Therefore roadmap is a integral part of strategy and goes beyond just a collection of features or requirements.

Minimum Viable Product

In product development, the minimum viable product (MVP) is the product with the highest return on investment versus risk. It is the sweet spot between products without the required features that fail at sunrise and the products with too many features that cut return and increase risk.

A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

An MVP can be part of a strategy and process directed toward making and selling a product to customers. It is a core artifact in an Agile methodology of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimize the total time spent on an iteration. The process is iterated until a desirable product/market fit is obtained, or until the product is deemed to be non-viable.

Product Backlog

The requirements in Scrum are called Backlog. Backlog is everything that is yet to be done and not necessarily the activities that the team has fallen behind.

The product backlog is an ordered list of requirements that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

The product backlog contains the Product Owner's assessment of business value and the Development Team's assessment of development effort.

The product backlog and the business value of each backlog item is the responsibility of the Product Owner.

The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Development Team, who contributes by sizing items, either in story points or in estimated hours.