27. 12. 2018 Michele Santuari Development, NetEye

Research & Development – Poker Planning (Part 3)

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.

Estimation Is Important, But It’s Also Hard

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.

Poker Planning

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:

  1. The moderator of the meeting selects the first not-yet-estimated task in the Backlog, and the owner of the issue describes that task.
  2. Other team members then ask questions about the task’s requirements.
  3. The estimate should take into account:
    • Effort:  How much time do you think you will need to work on it in order to finish it?
    • Complexity:  What do you already know about the task?  How well do you know the technology or the modules which will be used?
  4. When the issue has been fully discussed, each team member privately selects his or her estimate:
    • We use a deck of “Planning Poker cards” with numbers printed on one side.
    • As a unit of measure, we use powers of 2 between 0 and 64, where 16 means the complexity is not too great and the effort should take about one week, while 64 means the issue is exceedingly complex.
    • The effort estimation is associated with the issue as a Story Point.
  5. All team members then simultaneously reveal their Poker Planning cards with the number printed on it.
  6. If all team members selected the same value, that becomes the official estimate.  If not, the estimators discuss the reasoning behind their estimates.
  7. After further discussion, each estimator selects another Poker Planning card, and all cards are again shown.

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.

Using the Estimated Effort

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.

Michele Santuari

Michele Santuari

Software Architect at Wuerth Phoenix
Hi, my name is Michele Santuari and I am a Telecommunication engineer fell in love with OpenFlow, the first attempt of centralized network management, provisioning and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages.

Author

Michele Santuari

Hi, my name is Michele Santuari and I am a Telecommunication engineer fell in love with OpenFlow, the first attempt of centralized network management, provisioning and monitoring. I embraced the Software Defined Networking approach to discover a passion for programming languages.

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive