Why you should prioritize fresh for the sprint

An agile principle that we apply religiously here at ReQtest is that I as a product owner determine the priority just before each sprint. This is in contrast to the practice of having a detailed prioritization several sprints in advance.

We work in two-week sprints and because our team is not huge (we have a handful of really good developers) it is for obvious reasons that we do not have hundreds of requirements to decide on during sprint planning. In general, there are normally roughly a dozen requirements to be worked on for each sprint.

Recently, in a sprint planning meeting I included a requirement that was aimed at make the preview function better. The preview is a popular feature because it makes it easy to get a quick overview by moving the mouse over a number of issues instead of having to open each issue in order to understand what the issue is all about. In the current solution, when you hover the mouse over the preview icon, we display a few fields that we have defined. Users can add a few more fields to the preview, but only those that we have decided and only fields of the drop-down menu type. A neater solution would be to make it possible to preview all the fields in the issue, or perhaps even a setting so that the user can select which fields to display.

In this sprint planning I also had a requirement to introduce an entirely new type of field, namely a field type that contains all ReQtest users for the project. I know from talking to customers that this is a popular feature request as many users have the need to indicate which user is responsible for testing or development, or who the business representative is. I had concerns and reservations about this feature since it has an impact on quite a few different parts of ReQtest. The field should be logged in history, it should be possible to import/export data, bulk edit, help files etc etc.

I presented the requirements, we discussed them and then the developers carried out their time estimation using planning poker. Quickly, it became clear that the requirement for the preview was about as time consuming as the requirement to add a new type of field.

My decision became easy. Being able to add fields of new types is something that many users have requested. This requirement provides a much higher business value compared to better preview features.

If I had made the priority for several sprints at one time, I would probably never had discovered how expensive this requirement was in relation to the business benefits that the requirement delivers.

Therefore it is crucial to prioritize requirements when planning the sprint, not far ahead of time.