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.