Agile Prioritization and Estimation

1. Priority Levels for Features in Azure DevOps 

• Priority 1 - Features that have been reviewed and agreed upon by the full ITS Leadership Team as top priorities for the department and individual teams. These items will generally take precedence over lower priority items due to the value to the organization, however professional discretion should be used to ensure the most critical work is occurring for the University. Product Owners and Delivery Specialists should put the highest emphasis on these Features when to ensure progress is being made for timely completion. These Features should be in progress until they are completed, and can be closed once the success criteria is met. 
• Priority 2 - Features that are prioritized at the team level but are not identified as top priorities across the department. Product Owners and Delivery Specialists should regularly review these items to ensure progress is being made for timely completion. These Features should be in progress until they are completed, and can be closed once the success criteria is met. 
• Priority 3 - These items are buckets to contain operational user stories (e.g. communications, standard updates, etc.) and generally include items being worked on. These Features should be kept open all quadrimester as work is anticipated to come up throughout the quadrimester. 
• Priority 4 - This is the true backlog for the team for that quadrimester (i.e. "on deck" items). Items in a P4 status should not be worked on. Once the work becomes a priority, it should generally be moved to a P2 status. 

2. What is a Story Point?

A story point is a metric used in agile project management to estimate the duration of implementing a given user story. It is an abstract measure of effort required to implement it, that doesn't assume the exact precision of hours needed but rather assumes a reasonable range that includes complexities, risks, and unknowns.

Story point estimation, a kind of relative estimation, is typically performed at the Product Backlog Grooming or Planning sessions and is evaluated by the team responsible for the actual work. The estimate includes all of the work needed to fully complete a given deliverable (user story).

3. Why use Fibonacci Number

When the development team conducts an estimation, it is recommended to abandon the traditional “human-day” assessment method or try to calculate the exact number of hours it would take to complete all the work. Instead, it is recommended to use a sequence such as "Fibonacci Number", where the sizing exponentially increases, as stories get bigger, more complicated, and carry more risk, usually to due uncertainty.

The benefit of Fibonacci is that each number is roughly 60% greater than the previous one (with the obvious exception of 1 and 2, of course). This streamlines the conversation by preventing debates about whether a story is a 6 or a 7. The difference between a 6 and a 7 would be small enough as to not be worth the time needed to come to a consensus on it. So long as the team can come to a consensus about whether a story is a 5 or an 8 (which is a more significant difference), the estimation process will result in the desired outcome.

4.  How to convert Hours into Story Points

It is normal for a new team to still try to size User Stories by calculating the total number of hours needed to complete it. It is a natural inclination that will decrease over time, when the team gets more comfortable with the concept of relative sizing - "I have completed similar User Story last quarter and it took about 3 days, therefore, its a Large".

To help with translating hours into the Story Points, teams can use following criteria:

5.  Effort Sizing for Features in Azure DevOps

The SCSU Project Management Office will generally use the following for Effort sizing Features in Azure DevOps. Features should not be expected to take longer than 8 sprints. If longer than 8 sprints, the feature should be sized for what can be completed in 8 sprints with additional feature(s) created for remaining work. They can be grouped together as an Epic. If a Feature is anticipated to be less than 2 sprints, it should generally just be a User Story versus a Feature. 

6. Best Practices

• It is important that the team shares a common understanding of the scale it uses so that every member of the team is comfortable with it.

• Teams should establish an upper limit of "acceptable size" for User Story that can be committed in a sprint. Rule of thumb, no user story should take more than 50% of your sprint duration. For example, if your sprint is 2 weeks, 8 Story Points should be the maximum. Anything larger than that needs to be broken into multiple User Stories.

• When comparing two teams, Story Points should never be used as a performance metric to compare the effectiveness. Two teams are almost never alike when assigning story points to user stories.

• The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item. If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.