Skip to main content

How to plan a feature release as a Product Owner in an Agile team?


One of the questions that are often presented to a Product Owner is “When will a feature XYZ be ready for the customer?”. In this article I will walk through the process of planning and estimating a feature release in an Agile software development process. 

Let’s assume the Agile team is working on a customer lifecycle management product. The next increment for the product is to support a new communication channel like SMS. The business stakeholders identified this feature as a key differentiator from the competitors. According to the business stakeholders the release of this feature is time sensitive and consequently they would like to know when the feature will be available for the customers. This time-to-market information will be used to plan marketing campaigns to create awareness of the feature. Therefore as a Product Owner it's very important to plan and estimate a new feature. The following three steps outlines how a product feature release can be planned and estimated: 


Step 1: Identify the user stories to complete the feature
The Product Owner and the scrum team must brainstorm the user stories to complete the feature. At the end of this process the Product Owner must have a set of clearly defined user stories in the product backlog. Given that the feature is of high priority these user stories must be stacked at the top of the prioritized product backlog. This will ensure that the Scrum team creates the Sprint backlog with the user stories related with the new feature. 

The Product Owner must also collaborate with the Scrum team to estimate the level of effort required to complete each user story. The level of effort can be captured as story points.

The screen shot below describes how the user stories related to the feature is prioritized in the product backlog.

story-backlog-flow
by Beolle.com


Step 2: Use feature release map to plan and estimate
Let’s assume the Scrum team works in a 2 week sprint and can deliver on average 15 story points per sprint (this is also known as sprint velocity).  The Product Owner can map the user stories from the prioritized product backlog as shown below to estimate the number of sprints it may take to complete the feature. The screen shot below describes how the prioritized user stories can be mapped onto future sprints to estimate the feature release. In the example below the Product Owner can estimate 3 sprints (i.e. 6 weeks) to deliver the new communication channel feature.  

sprint-points
by Beolle.com

Step 3: Maintain the feature release map
The Product Owner must update the feature release map at the end of each sprint to reflect any changes to the prioritized product backlog. This may be necessary if the scrum team discovers new information that may result in additional user stories. The Product Owner can then use the feature release map to check the status of the feature development. The feature release map can also be used to collaborate with the scrum team to identify creative approaches to meet the estimated feature release timeline.

In conclusion a feature release map is a very helpful tool for a Product Owner to plan, estimate and manage a new feature release. The map can be created using easily available tools like Microsoft Word, Visio, Lucidchart, etc. However there are dedicated tools like FeatureMap that can also be used to map user stories.


---------------------------------------------------------------------------------------------------------------------
Image credit:
The thumbnail image of this article is by Daria Nepriakhina on Unsplash

Trending posts

Designing Habit Forming Mobile Application

Mobile Applications have become an integral part of our daily lives - we use mobile apps as alarm clocks to wake us up in the morning, to create to do lists when we start our day, to communicate with our colleagues at work via apps like Skype. We even check reviews of restaurants to visit on apps like Yelp and we seek entertainment on apps like Netflix and spotify. So what drives us to use these apps so seamlessly in our daily lives? Why we prefer some apps over others? Is there a science behind designing successful mobile apps like Facebook?   A study in US revealed that a user between the age of 18 and 44 visits the Facebook app on average 14 times a day [1]. This shows that using the Facebook app is a daily routine for many of its users. This makes Facebook a great example of a habit forming mobile app which is designed with human psychology in mind that encourages habit forming behavior in its users .   I recently attended a seminar on the design of such habit forming mo

Research around JIRA vs TFS

By: Carlos G.    An opportunity came from a colleague to discuss the case of company “X” for improving the ALM by introducing tools to this company. The challenge was to decide between Microsoft and Attlasian . He came to me because I’m a Microsoft kind of guy and he wanted the opinion from my perspective, not as a consultant, but as a friend of what he was trying to accomplish. He said that even though I was inclined to a technology I was able to explore other things and be “fair”. I agreed to be a part of his research because of 3 things: because of my curiosity I'm always willing to learn new techy stuff. Sometimes is good to be the dumbest one of the group. You learn so much! This was a story that I could blog about. (Of course no names are used in this post). My first impression was thinking “cool”; let’s compare Visual Studio TFS vs JIRA. Immediately I got a comment back with: “ Sure but JIRA by itself is more like an issue tracker in simple terms ”. That sa

AWS Amplify as low-code for infrastructure

Low-code development platforms are dominating many conversations lately. Many believe that low-code development platforms will account for millions of USD in revenue in the next five (5) years. An article by Forbes highlights that “ it will account for more than 65% of application development activity by 2024 ”. Some believe it will be the answer to all their development needs. Photo by Tima Miroshnichenko from Pexels  But low-code is not a new concept. The difference now is that its audience has amplified. For developers (or even advanced users) who have been in the Microsoft  ecosystem for a while have already experienced the assembly of software solutions with little effort using tools such as Microsoft Excel, Access, Visual Studio (assembling forms) and others. Putting Microsoft aside, and prior to this “low-code revolution” which has reached high altitude in the last couple of years, there have been many online veterans which allow a user to assemble simple to medium complex

This blog uses cookies to improve your browsing experience. Simple analytics might be in place for pageviews purposes. They are harmless and never personally identify you.

Agreed