I described in a prior blog post the so-called Backlog which is used not only by the Research & Development team but also by the other teams in the System Integration unit. The Backlog Refinement meeting is focused on the prioritization and re-ordering of tasks, and this activity cannot be achieved without properly estimating effort.
In this blog post I describe how the Research & Development team evaluates and estimates the effort required for each new feature, improvement or bug fix, leveraging the Poker Planning technique.
Prioritization of features and improvements in the System Integration Unit is a consensus-based process which involves not only the Product Owners, but also the Development Team at the Backlog Refinement meeting. Prioritization impacts not just product development, but also the business strategy.
You can imagine how difficult it is to decide whether to prioritize one task over another when you have no idea how long it will take the team to deliver it should they start working on it today. And especially when the Product Owners are not aware of the low-level implementation details and, as a consequence, cannot know how much effort will be required by that feature or improvement.
Thus effort estimation is very important for conducting the Backlog Refinement meeting, but arriving at a precise estimate is very hard because it depends on many factors which are difficult to take into account.
As a consequence, in recent months the Research & Development team has begun using an agile technique called Poker Planning to estimate the effort of upcoming tasks.
Agile teams around the world use Poker Planning to estimate the tasks in their product backlogs. Poker Planning is a consensus-based estimating technique. The precise estimation of upcoming tasks should be a team activity in which each team member should be able to present his/her perspective and help evaluate the effort required for each task without being influenced by other team members.
The Poker Planning method fulfills this requirement as follows:
You cannot imagine how many differing viewpoints, which otherwise would have not been taken into account, are raised during the discussion phase that then help us arrive at a more correct estimate.
The estimated effort is used by the owner of a task to decide if the complexity and effort of each task are reasonable.
For instance, for us new features and improvements must have a Story Point that is less than or equal to 16. This means that issues estimated to be higher than 16 must be broken down (split) into more granular pieces. Split issues are then readdressed at the next Poker Planning meeting.
The end result is that the Research & Development team can continuously deliver features and improvements without getting stuck in tasks that take too long and not realizing it. Moreover, shorter tasks are easier to estimate and help identify potential feedback cycles that can produce adaptations, re-engineering and improvements.
Finally, the Poker Planning process provides a way to learn from past estimates to improve the correctness of future estimates. We thus record both estimated and actual time for each issue in order to compare them systematically at a later date.