What factors are needed to prioritize themes?

Need of users is considered before planning for a project. To achieve the best combination of product features, schedule, and cost requires deliberate consideration of the cost and value of the user stories and themes.
We need to prioritize and this responsibility is shared among the whole team. Individual user stories or features are aggregated into themes. Stories and themes are then prioritized relative to one another for the purpose of creating a release plan.

There are four primary factors to be considered when prioritizing:
1. The financial value of having the features.
2. The cost of developing new features.
3. The amount and significance of learning and new knowledge created by developing the features.
4. The amount of risk removed by developing features.

1. Determine the Value of Theme
- Estimate the financial impact over a period of time.
- It can be difficult to estimate the financial return on theme.
- It usually involves estimating number of new sales, average value of sales and so on.

2. Determine the Cost of Developing new Features
- Estimating cost of a feature is a huge determinant in overall priority of a feature.
- The best way to reduce the cost of change is to implement a  feature as late as possible.
- The best time to add feature is when there is no more time to change.
- Themes seem worthwhile when viewed in terms of time they will take.
- It is important to keep in mind that time costs money.
- The best way to do this while prioritizing is to do a rough conversion of story points or ideal days into money.

3. Learning New Knowledge
The knowledge that a team develops can be classified in two areas:
Product Knowledge
- It is the knowledge about what will be developed.
- It includes knowledge about features that are included and the features that are not included.
- Better knowledge of product will help the team to make better decisions.

Project Knowledge
- It is the knowledge about how product will be created.
- It includes knowledge about technologies, skills of developers, functioning of team together etc.
- The other side of acquiring knowledge is reducing uncertainty.

4. Risk
- A risk is anything that has not happened yet but might happen. It would threaten or limit the success of the project.
- Types of risks involved in a project are : schedule risk, cost risk and functionality risk.
- Struggle exists between high risk and high-value features of a project.
- Each approach has its drawbacks and the only solution is to give neither risk nor value total supremacy when prioritizing.

All these factors are combined by thinking first of the value and cost of the theme. Doing so will sort the themes into an initial order. Themes can then be moved forward or back in this order based on the other factors.

When to re-estimate? What is a better way to estimate : Story points or Ideal Days?

When to Re-estimate?

Story points and ideal days are estimates of the size of a feature which helps you to know when to re-estimate. Re-estimate is done only when your opinion of the relative size of one or more stories has changed. One should not re-estimate just because progress is not coming as rapidly as expected.

Velocity should be allowed to take care of most estimation inaccuracies. Velocity is considered to be a great equalizer. The reason behind this is that the estimate for each feature is made relative to the estimates for other features, it does not matter if our estimates are correct, a little incorrect, or a lot incorrect. What matters is that they are consistent. As long as we are consistent with the estimates, measuring velocity over the first few iterations will allow us to have a reliable schedule.

At the end of an iteration, it is not recommended giving partial credit for partially finished user stories. The preference is for the team to count the entire estimate towards their velocity (if they completely finished and the feature has been accepted by the product owner) or for them to count nothing toward their story otherwise.

However, the team may choose to re-estimate partially complete user stories. Typically, this will mean estimating a user story representing the work that was completed during the iteration and one or more user stories that describe the remaining work. The sum of these estimates does not need to equal the initial estimate.

A team can choose to estimate either through story points or ideal days. Each has its advantages.


Benefits of Story Points
1. They help drive cross functional behavior.
2. The estimates derived by story points do not decay.
3. Story points are a pure measure of size.
4. Estimation through story points is faster.
5. Unlike ideal days, story points can be compared among team members. If one team member thinks that it will take him 4 ideal days, and another member thinks that it will take him 1 ideal day, both of them may be right yet there is no basis on which to argue and establish a single estimate.

Benefits of Ideal Days
1. They are more easily explained to those outside the team.
2. They are easier to get started with.

The advantages of story points are more compelling as compared to benefits of ideal days. one way is if a team is struggling with estimating the pure size, they can start off with estimating with ideal days and gradually switching to estimating by story points.