When are Story Points and priority estimated in the planning phase of agile?

Question

In our agile requirements gathering sessions (not sure of the technical name sorry), where we engage with the product owner to list all stories that are required for the implementation, we typically estimate story points and priority as we go.

Is this the correct methodology? And further is it the most effective? Or should we be listing all our user stories, then going back and prioritising and estimating SP?

Answer 1

Story point estimating and prioritisation is a continual process in agile.

The most important thing is to have story point estimates and prioritisation done for the work that the team is about to do. Typically this would be 1-4 weeks worth of the backlog. It is less important to have estimates and prioritisation done on stories that are further in the future.

That is not to say there is any harm in estimating and prioritising ahead, just that we must always allow for the possibility of change. So the long-range estimates and prioritisation should be treated as likely to change.

A common approach is as follows:

• The team makes a start at gathering requirements. They focus on the work they are likely to do first, perhaps 1-4 weeks worth of requirements.
• The team prioritises and does story point estimates for the work they are about to start on.
• The team starts work.
• As the team is working they allow some time for refining their backlog of requirements. For example, in Scrum we use 5-10% of the team's time on refining the backlog.
• When the team refines the backlog it will often do some more story point estimating and prioritisation.

Think of it as a pipeline of requirements. The team is working on the highest priority requirements and is simultaneously planning for the next set of requirements they will do. The advantage of this approach is that it is very easy to accomodate change. If the requirements or priorities change it is easy for the team to adapt as they are not too far ahead with their planning.

There are some situations where the team may want to do story point estimates and prioritisation further in the future (say a month or two ahead). Teams often do release planning when they want to focus on a particular milestone of functionality. The team knows roughly the rate at which they get through stories (i.e. they know their velocity in story points per iteration) and so by estimating further ahead on the backlog they can guage roughly where they will be in the future.

It is important that these longer term plans are viewed as not being set in stone. Because the agile approach emphasises adapting to change we anticipate that change will happen. So we will usually continuously adapt our medium and long-term plans as we go along.