Questions about estimation and sizing

1. 1. If during the sprint, the developer found out that a feature is worth 5 points and not 2, should he update the size in the sprint backlog or not? And why? Thanks! :)

If he didn't, would the Sprint Backlog then capture the best estimate of the work that is believed to remain?

2. A feature worth 5 points is almost done by the end of the sprint, but did not meet the DoD. The PO then decides to prioritize it on the next sprint. Should the team re-estimate it based on the remaining work that needs to be done?

A feature that is "almost Done" is worth nothing. There may however be less work remaining until it becomes usable and worth something.

If the team had no transparency over work remaining, how would they then plan?  

3. Is there an advantage to estimating in hours instead of points?

I'm sure there will be advantages to some teams operating in their context. For others, it would be more advantageous to estimate using points.

The disadvantages lie in trying to be prescriptive about how estimation ought to be performed, irrespective of context.

4. Is forecast vs actuals a bad metric (and it probably is)? Why?

If it is used by a team to inspect and adapt their ability to take on work to meet a goal, it is potentially a good metric. If it is used by stakeholders as a proxy for value, it is likely to prove a lousy one.

1. If during the sprint, the developer found out that a feature is worth 5 points and not 2, should he update the size in the sprint backlog or not? And why? Thanks! :)

What would be the value in doing this? Once the work has been started, is it worth the effort to figure out if the work was really a "2", a "5", or something else? Once Sprint Planning has occurred, there's very little remaining value in the size estimate. Perhaps if something was very inaccurately sized, it may be a good discussion point during the Sprint Retrospective, but the primary focus of the team should be in understanding what work must be done to achieve the Sprint Goal and getting it done.

2. A feature worth 5 points is almost done by the end of the sprint, but did not meet the DoD. The PO then decides to prioritize it on the next sprint. Should the team re-estimate it based on the remaining work that needs to be done?

What is the value in reestimating? I don't like to talk about "almost done" work. The work is either done or it is not done. The work, based on some description, has been estimated to be of a certain size, complexity, or level of effort. I don't see any reason to regularly reestimate work just because it isn't done. The description of the work is still a certain size. Plus, other changes to the product or knowledge gained may lead to rework that wasn't originally captured.

3. Is there an advantage to estimating in hours instead of points?

What does the team prefer? There are different purposes for estimating work. Sometimes, it can be useful to see if the team generally agrees on the size and scope of the work and highlight potential areas of disagreement or ambiguity. Other times, it can help the team to plan their Sprint more effectively. What does the team hope to get out of their estimates? I've found that relative sizing (in t-shirt sizes or points) is good at ensuring the team can agree on the work, while hours may be better for more detailed Sprint Planning, but I've worked with teams who have had success with both.

4. Is forecast vs actuals a bad metric (and it probably is)? Why?

Why would it be good? Forecast vs actuals focuses on outputs, rather than outcomes. What if the key objective, the Sprint Goal, was only related to one or two Product Backlog Items? If the team is consistently delivering on their objectives and goals, does it really matter so much if other forecast work was getting done or not? How do you account for changing capacity? In my experience, looking at forecast versus actual completed work hides important information and focuses on the wrong things.

1. If during the sprint, the developer found out that a feature is worth 5 points and not 2, should he update the size in the sprint backlog or not? And why? Thanks! :)

How would they know the difference unless you have a very clear definition of what a "point" means?  Estimates are based upon what you know at the time you make the guess.  So what you are asking is should the developer change their guess?

I also ask about the "the developer found..." statement. It leads me to believe that individual developers are estimating the stories instead of the team coming together on an agreement to each one.  In the first case, how would you know that Developer A's 5 point estimate isn't Developer B's 2 point estimate.  

2. A feature worth 5 points is almost done by the end of the sprint, but did not meet the DoD. The PO then decides to prioritize it on the next sprint. Should the team re-estimate it based on the remaining work that needs to be done?

In my experience, it does not good to do so. The estimate is for the story. Just because some of the work has not been completed, the story hasn't changed.  So the estimate should remain the same. And who's to say that the team won't discover more information that changes the remaining work?  

What benefit would the team get from re-estimating?

3. Is there an advantage to estimating in hours instead of points?

Some teams might think so but in the end, they are just guessing based upon what they know.  How would they know if something is going to take 3 or 4 hours?  And does it really matter? The modified fibonacci is used for Story Points because it shows a graduated difference. The difference between a 5 and a 8 is easier to understand than a difference between a 5 and a 6 when estimating hours. 

In the end, this is up to your team to decide but have any of them expressed a concern over the way it is being done now?

4. Is forecast vs actuals a bad metric (and it probably is)? Why?

If you are intending for your estimates to be the forecast and actuals to be the work, then it is a bad idea.  You are not using the same basis for the comparison.  An estimate is a guess made based upon the information you have at the time you make a guess.  Actuals are based on what happened after you started to work on the item.  Two completely different paradigms. 

I have question regarding the estimation for developers. If the story point calculation works as follows:

1. 1 story point = few minutes
2. 2 story point = few hours
3. 3 story point = a day
4. 5 story point = few days
5. 8 story point = a week
6. 13 story point = a month

So how will a scrum master calculate the capacity for developers, in order to assign the stories to developers as per their capacity?

So how will a scrum master calculate the capacity for developers, in order to assign the stories to developers as per their capacity?

Story points, which are optional in Scrum, are relative sizes and do not correlate to time (minutes, hours, days, weeks, or months).

A Scrum Master never assigns stories (Product Backlog items in Scrum terms) to Developers. Based on past empirical evidence, developers figure out how much work to pull in, and as a team, they determine how to complete the work. Velocity is sometimes used to figure out capacity based on what a team has historically been able to get 'done'. There are other more advanced ways as well using flow metrics.

A self-managing group of Developers should be able to calculate their capacity.

I agree with @Chris, converting story points to days/hours defeats the purpose of story points (which is a relative estimate).

1. 1 story point = few minutes
2. 2 story point = few hours
3. 3 story point = a day
4. 5 story point = few days
5. 8 story point = a week
6. 13 story point = a month

Even if you would do a conversion as above (though should not be done), having different units is confusing. Why not set 1 SP= 1 day and based on your sprint length you know number of days per person (consider time off period for the team).

I'm going to start by suggesting you read this post by Ron Jeffries about the origins of story points. (https://ronjeffries.com/articles/019-01ff/story-points/Index.html)  

Story points are supposed to be relative estimates.  Your scale shows "few hours" and "few days" so I guess it is relative. But is 18 hours a "few hours"?  Is "5 days" a few days?  How would you convert that to capacity.  In my opinion, the capacity of every team member is "a few days" so they would each be able to do one of those story sizes in a Sprint.

The Developers should be able to determine how much work they can do as a team during a Sprint timebox.  They can use the relative estimates as a tool for that.  But it is up to them to decide how much and what work to do during the Sprint. The commitment for a Sprint is the Sprint Goal, not to complete a certain number of hours writing code. The Sprint Goal helps them to keep focus as a team on what work is important for the current Sprint.