Estimating Product Backlog in Azure DevOps

Product Backlog in Azure DevOps

Azure DevOps has a feature namely Azure Boards. As we know, Azure Board is a requirement management system in our formal or agile process. On this article, we will discuss how to estimate the product backlog in Scrum or to estimate the user story in Agile process. In Azure boards you can fill the comprehensive information such as:

• Product Backlog name: it can be any format but my recommendation is : Actor + Action + Entity. For example, Admin Manages Product Group
• State. It shows the status of the product backlog
  • New – it is created by product owner
  • Approved – it is discussed with the customer / stakeholders
  • Committed – it is understood by the developers
  • Done – it is tested by the QA
  • Removed – it is removed by the product owner
• Description. It can be composed in two models
  • Simple model: it uses "as an (actor) I want to (action) so that (benefit)". For example. "As an admin I want to manage product group so that admin can create variant later"
  • Comprehensive model: it uses usage scenarios model. For example, 1) admin clicks product group menu 2) system displays the existing the product group menu that contains of ID, product group name, and numbers of variance.
• Acceptance criteria. It provides list of definition of done of our customers. For example. 1) at least admin should input the product group name 2) there is no similar product group name 3) the product group name maximum length is 255 characters.
• Discussion: any changes or questions should be added here.

Estimating the product backlog

After you complete the product backlog. It is time to fulfill the estimation model. The estimation model can be established in Planning Game or Sprint Planning. In the sprint planning you can estimate:

• Priority. There are four level. It is defined by the customer
  • Level 1 – Urgent and Important
  • Level 2 – Not Urgent but Important
  • Level 3 – Urgent but not important
  • Level 4 – Not urgent and not important
• Effort. You can use Fibonacci or the Power of Two estimation. It is defined by the developer
  • Fibonacci: 1, 2, 3, 5, 8, 13
  • Power of Two: 1, 2, 4, 8,
• Business value. Business value is communicated with customer and defined by the product owner
  • 1 – essentially needed
  • 2 – adding business value
  • 3 – nice to have
• Value area. it relates the business value
  • Business process: the product backlog provides better business process transformation for the business.
  • Architecture: the product backlog provides better reliability, security, performance, etc.

Tips on estimation model in Product Backlog

There are two types of estimation in product backlog

• Relative estimation. For example, this project is twice complex than the previous project. This kind of estimation is given by the product owner when meeting with the customer before the proposal is submitted. The main idea is providing a mindset of customer about the complexity, cost, and resources.
• Absolute estimation. For example, we can finish the project in 34 days maximum. This kind of estimation is given by the product owner after the proposal is submitted and the mockup is delivered. The main idea is providing prediction to the customer. There are three levels of prediction
  • Best case – 100% of estimated points
  • Normal case – 125% of estimated points
  • Worst case – 150% of estimated points

Estimation can be achieved by using story points.

• Relative estimation: the user story of product group is 13 points
• Absolute estimation: 13 points x 3 hours / points = 39 hours. That is best estimation. You can find normal case in 39 hours x 125% = 48,75 hours. How about the worst case? Can you guess it.

Do you have idea how to make the estimation better? Put it in the comment section.