One of the most critical activities by the development team in Scrum is ordering the product backlog into sprint backlog. As you know, the product backlog is a user story that developed by the product owner based on the interaction between the product owner and the customer. When product backlog is agreed between customer and the product owner. The product backlog will be stored in a 'place' where the development team can take it and put it on a sprint. A product backlog should be estimated, prioritized, and refined first before putting into a sprint. You can read the estimating method on this post Estimating Product Backlog in Azure DevOps (ridilabs.net). Estimating product backlog gives the information about the size of the product backlog. However, it doesn't give any information about the order of the product backlog. To do that, we need to do several steps such as:
- Estimating the product backlog effort size. For example, "as a admin I can set role the employee so that each employee will align with the department and job description". After the discussion, we conclude the 13 points.
-
Converting the points into a duration. This approach will convert the points into the duration of each point. We name it as velocity. Velocity unit is hours/point. Therefore, the duration will be effort size (points) x velocity (hours/points). The velocity can be obtained from the
- Machine learning / prediction of the length. The idea is grabbing a lot of project data and find the similarity between product backlogs and project types. This can be used for anyone who want to get prediction of the duration
- Historical analysis. The idea is using the history of the team based on similar project. This can be done of you already have similar project.
-
Finding the relation of the product backlog. There are two types of relation
- Depend on. Profile page depends on the registration page.
- Is a dependent of. Registration page is a dependent of profile
-
After that you can short the product backlog based on dependency for example. You can create matrix of dependency
- The higher depend on means you should consider build the product backlog later
- The higher dependent of means you should consider build the product sooner
- After the ordering you can combine the ordering with the priority. The highest priority should be developed first. If many of the product backlog has many similar priorities try to pick the easiest one.
- Now you can split the product backlog into sprint backlog. The idea is to deliver value. So, you can combine two product backlogs into one sprint in order to deliver a value. For example. One sprint length is defined as three product backlogs that have equal in 25 points. The three product backlogs have same value for example: registration, profile, and activation. It has 25 points. If each point equals with 8 hours. It means the sprint length will be 25 points x 8 hours / point. Or 200 hours. You can convert into days when you need to.
Some Research agenda
- How to define the velocity in cold start
- How to define the sprint length
- How to order the product backlog in a sprint