Contents:
What are the story points?
Story points are used in agile methodology and user story mapping. Most agile teams use story points for estimation when planning sprints to estimate the team's velocity, and quantify the amount of work required to deliver the task or user story in the product backlog.
In contrast, traditional and T&M contract software teams provide estimates in a time format of hours and days - largely for easier accountability of the work done.
Story point estimation can be a difficult and agile process, but it shouldn't be. There are three factors that usually taken into account to determine the value of story points:
Risk describes the degree of uncertainty associated with the implementation of a task, which may be influenced by, for example, the characteristics of client-side decision-making or the reliability of the technologies used.
Amount of work: reflects the speed of expected progress and the development team's previous experience with similar tasks.
Complexity describes the level of difficulty of the task.
What matters is not the actual numerical value of the story points, but only their relationship to each other. The use of story points can vary from organization to organization, or even from team to team.
How to estimate story points?
After the backlog prioritization, the next step is to estimate the story points. Its purpose is pretty similar: to get everyone involved who will be working on the implementation such as developers, designers, testers, DevOps engineers, etc. Each team member can bring to the discussion their perspective on the product and the subjective perception of the work required to deliver the user story or task. The personal involvement of team members in the estimation is also essential to get the team on the same page, i.e. to make sure that everyone is aware of what is being developed and why.
To calculate the story points, you should use a technique called planning poker. The team selects an item from the product backlog, discusses it briefly, and then each team member holds up a card with a number corresponding to their estimate. Agile teams typically use the Fibonacci Sequence, a variant of it, or T-shirt sizes.
If there is an agreement, they can move on to the next product backlog item, if not, they briefly discuss why some members see it easier or harder to complete the task and come to a joint decision.
The resulting history point matrix makes it easy to see how many backlog items the team can complete in the upcoming sprint.
Story points and effort fields in Azure DevOps
This procedure is only needed if you like to link Azure DevOps to StoriesOnBoard only on the story cards level.
Some work items (like issues) in Azure DevOps don't have a story point or effort field by default. Like that StoriesOnBoard can't sync with those fields unless we add them manually. Let's see how to do that.
In case you selected the issue for example as "Exporting work item type" and also checked the option "Synchronize estimation changes as Story points or Effort" you will get the following warning message.
To solve this problem, please go to DevOps and open up one of the problematic work items (in our example I'll open up an issue work item), then from the "..." menu on the right side select "Customize".
Click on "New field", select "Use an existing field" and Story Points or Effort from the drop-down, click on "Add field".
Now you can get back to StoriesOnBoard and validate your configuration. After this process, the estimation sync should work between the tools for these work item types.