31. 12. 2023
Development, DevOps, NetEye
27. 12. 2018
Michele Santuari
NetEye, Unified Monitoring
Research & Development – Planning Poker (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 Planning Poker 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 Planning Poker to estimate the effort of upcoming tasks.
Planning Poker
Agile teams around the world use Planning Poker to estimate the tasks in their product backlogs. Planning Poker 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 Planning Poker method fulfills this requirement as follows:
- The moderator of the meeting selects the first not-yet-estimated task in the Backlog, and the owner of the issue describes that task.
- Other team members then ask questions about the task’s requirements.
- 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?
- 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.
- All team members then simultaneously reveal their Planning Poker cards with the number printed on it.
- If all team members selected the same value, that becomes the official estimate. If not, the estimators discuss the reasoning behind their estimates.
- After further discussion, each estimator selects another Planning Poker 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 Planning Poker 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 Planning Poker 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
Software Architect at Wuerth Phoenix
Hi, my name is Michele Santuari and I am a Telecommunication engineer felt 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. Now, I am into Agile methodologies and crazy development process management.
Author
Latest posts by Michele Santuari
28. 12. 2020
Development
Research & Development – Spike (Part 4)
23. 12. 2020
Development
RPM/ISO Repository: Disk Space Optimization
05. 10. 2020
Development, NetEye
Research Activities: A Fully Distributed NetEye