When a new product or a set of new product features providing some value to customers or end users is launched in the market, the launch activity is described as a product release. A product release helps to create a value stream for business owners. Its function is to bring in capital for the business by generating a profit. Product based companies – especially those following a SaaS model – have to depend heavily upon releases to grow and sustain their growth over time.

Organizations can grow only if the products they manufacture are released at the correct time and in the correct manner. If a product is released prematurely before it can be properly tested and made shippable, it could result in end users experiencing bugs or regression. This can lead to a bad user experience and even affect brand reputation. On the other hand, if a product is released too late it could prevent the organization from availing the business value in the time leading to stressful financial conditions for the project owners. Projects may be forced to close down if they can’t sustain themselves over time. Therefore releasing the product in the right manner at the right time is very important.

Both traditional Waterfall processes and Agile methods facilitate product release. However, the manner and frequency of the releases vary considerably depending upon which method or process is employed by the team to manage the software project.

Doing it the traditional way

Traditional processes are best suited when the scope and time of the project are fixed. However, in practice, stakeholders may request changes in existing features and functionality as and when market conditions change. This can delay the development process and extend the deadline since the team may be forced to take up unplanned design and/or functionality related work which it has not anticipated and accounted for at the time of project inception. In Waterfall processes as the project completion and the release date are fixed at the onset, the development team is often kept under pressure to deliver work – both planned work as well as feature changes related – within the stipulated deadline. Teams may find it difficult to cope up with the added development activity and start cutting corners to complete work in time. As a result, the release may contain bugs and have faulty functionality which reduces user experience and even lead to a bad brand image.

Owing to the staged process flow, Waterfall processes are irreversible in nature. The product can be released only after the project completes. Moreover, since only a single version of the product can be designed at a time in the project, you can’t have multiple product releases supporting upgrade versions for the same product in the same project. It’s also difficult to address risk mitigation since defects found in later stages cannot be reworked upon and corrected by reverting back to prior stages. It can be also difficult to adapt to changes in the product design once the project is documented and the development process starts. Therefore the business value of the release cannot be increased or enhanced once the project deliverables are decided.

Thus, you can be sure of releasing your product on time using traditional methods only if you’re absolutely sure about the project’s scope, know exactly what you’re going to design and develop in your project and whether you can estimate your team’s velocity (the speed or rate at which the development team can complete work in a given duration of time) correctly.

How Agile does it

The success of a product release depends primarily upon what functionality the features offered in the release and how useful they are to end users. The business value in a project can be availed only if the releases are properly designed and planned. To make a release valuable, Agile tends to focus upon the following aspects:

• Can the business value be delivered in the form of a releasable product?
• Is the goal of building a reliable product with the desired quality met?
• Can the project successfully deliver the product releases on time?

1. Planning the releases

In Agile since development is carried out of the product on incremental cycles bases, the release of a product depends primarily upon the development team’s velocity metric which indicates how much of work the team can handle or get done per iteration cycle. Given the speed at which the team can deliver shippable product features, it can be planned how many sprints are required to develop a particular set of features. The features set is made available to the end users in the form of a release. The goal of a release is to deliver working software to end users as quickly as possible.

For explanation, suppose a product has 9 features. If the team has a capacity of developing 1 feature per iteration cycle or sprint, and each sprint lasts for 2 weeks, a release containing a set of 3 features can be released in the market every 6 weeks. Since the product contains 9 features, if 3 features are planned for each release, it would take 3 releases to launch the entire product.

• As the team becomes more conversant with the product with each development cycle, it tries to improve upon its velocity metric and speed up development work. More work can be taken up by the team per sprint which can reduce the total number of releases required to launch the product.
• Since features are launched in sets in releases, it becomes possible to receive end-user feedback at the end of each release rather than receiving the feedback after the entire product is deployed. Product owners can plan further rework to enhance the business value of the features even while the product is being developed. The rework can be taken up by the team as a “feature enhancement” task which can include all suggestions provided by end users to make the feature functionality more useful and powerful.
• Business value is delivered to the client at the end of each release. Therefore, it becomes easier to achieve the breakeven point and fulfill the marketing milestones.

2. Designing the sprints

A sprint is a predefined duration in days (generally lasting 1 or 2 weeks or more but not extending 1 month) during which the team develops valuable shippable software and delivers it to the client. Each sprint is planned in a special Agile event known as the sprint planning meeting. During sprint planning sessions, the product owner (a person responsible for delivering the value in the project) selects a few valuable and prioritized product development tasks (user stories) and presents them to the team for development purposes. The team decides how much work (number of tasks) it can complete in the development cycle (sprint) and creates a sprint backlog (a list of finalized features and working functionality) to be completed during the upcoming sprint.

The team understands how each feature is to be developed and what criteria (acceptance criteria) should be fulfilled so that the particular feature can be considered as successfully completed (fulfill the Definition of Done). If the team has any doubts or needs any clarifications the product owner helps the team to understand the deliverables and what end users expect out of the proposed functionality.

The team members i.e. the developers, designers, testers, technical writers, database administrators etc. than take up the proposed tasks from the sprint backlog based upon their levels of expertise and start decomposing the work (tasks) in a manner such that each task can be developed independently (provided they don’t have any dependencies).

Working software is then developed by the team during the sprint.

The objective of a sprint planning session is to:

• Establish a clearly defined goal for the sprint.
• Choose valuable and important tasks or user stories that support the sprint goal.
• Break or decompose work (user stories) into specific development tasks.
• Create a sprint backlog.

3. Prioritizing the product backlog

Broadly speaking, the product backlog is a list of all activities (feature development, testing, documentation, and deployment) needed to build the product. Each project has a product vision that explains what the final product should be like i.e. what kind of features the product should have, what type of functionality the features should offer, how end users shall use the features etc. People involved with the project viz. stakeholders, end users, technical team and the product owner suggest feature requirements and functionality that can fulfill this product vision.

The product backlog, therefore, is a “wish” list of all functionality desired in the product and keeps on growing in size over time as more and more requirements keep on adding in the list. Agile focuses upon the development of most valuable and important features first followed by less important ones so that maximum value in the project can be tapped and delivered in the form of working software to the client at the end of each product incremental cycle – the sprint. Hence it is required to arrange the product backlog such that valuable and most important tasks or development activities are contained at the top whereas less important requirements are placed in the middle. The process of prioritizing the product backlog as per the business value of the stories contained in it is also known as “backlog refinement” or “backlog grooming”.

Product monetization in Agile and traditional methods

Using the tool

1. Creating user stories for capturing requirements

Requirements in the form of user stories can be added dynamically to the product backlog:

        [Place Image]

https://www.quickscrum.com/ProductBacklog/ProductBacklogList

Alternately, you can also add the stories while planning the sprint:

        [Place Image]

https://www.quickscrum.com/Sprint/SprintList

… or even while using the Scrum board:

        [Place Image]

https://www.quickscrum.com/Task/TaskList

To find out more about adding stories visit:

https://www.quickscrum.com/Help/119/add-a-story

2. Detailing the stories with relevant information

User stories form the base of all development activity. Therefore, for teams to develop meaningful and useful features, each story should be properly described and detailed by the client, end user or the person who requests the functionality. The value of a story depends upon how well its acceptance criteria is stated. The acceptance criteria is a set of statements with each state having a clear pass/fail result. The statements specify both functional and non-functional requirements. To find out more how to state the acceptance tests please visit:

https://www.quickscrum.com/Help/138/define-acceptance-criteria

3. Prioritizing stories as per their importance and business value

The value of a project i.e. its ROI depends a lot on how stories are estimated and prioritized in the product backlog. To deliver high-value stories on a consistent basis, it is important to organize the backlog in a manner such that important and valuable stories can be found on the top and easily picked up for development purposes. To understand how to rearrange stories as per their importance please visit:

https://quickscrum.com/Help/38/prioritize-story

4. Designing the sprints

Stories or feature tasks are developed in product incremental cycles called sprints. A few valuable and important stories – just enough number of stories that the team can successfully develop in a sprint and not more or less – are selected from the top of the prioritized product backlog by the team for development purpose. The team then discusses how the stories should be developed, what parameters should be fulfilled for the story to be considered as successfully developed (made shippable) and how the team members should decompose the stories into individually developable parts. The stories taken up for development are listed in a backlog called “sprint backlog”. The team then starts with the actual development work as the sprint commences. To find out how to design the sprints please visit:

https://www.quickscrum.com/Sprint/SprintList

To read more about sprint designing visit:

https://www.quickscrum.com/Help/56/sprint-planning

5. Planning the releases

A release is made up of one or several sprints. Keeping the product vision and roadmap in mind, sprints are included in the release plan based upon what features are developed in them, and how much of value the sprints will deliver through the sprints. To read about how to plan your release please visit https://www.quickscrum.com/Help/185/sg-Release-Planning. It is very easy to create your release plan using the tool and you can find how to do it at https://www.quickscrum.com/Help/49/release-planning.

Conclusion

A release plan provides a common vision to the team regarding what goals need to be achieved, how and when. It helps the team to decide upon priorities and make informed decisions. From the management’s point of view, a release plan offers a roadmap as to how the client and stakeholders can earn back their investment amount and plan further growth. Traditional project management processes support a single release plan whereas in Agile you can have multiples releases to avail the business value in the project at regular intervals of time. Find how Agile helps to monetize your work efforts in a short passage of time and how you should plan your product release using the Agile process.