One of the main purposes of grooming is to estimate the tasks.
When starting out as a developer I was used to giving Time estimates against tickets, since moving towards Agile and then moving into Project Management I’ve been using the Fibonacci sequence (1, 2, 3, 5, 8, etc.) under the planning poker.
The reason to use Planning poker is to avoid the influence of the other participants. If a number is spoken, it can sound like a suggestion and influence the other participants’ sizing. Planning poker should force people to think independently and propose their numbers simultaneously. This is accomplished by requiring that all participants show their card at the same time.
At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.
The meeting proceeds as follows:
- A Moderator, who will not play, chairs the meeting.
- The Product Manager provides a short overview. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager.
- Each individual lays a card face down representing their estimate. Units used vary – they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
- Everyone calls their cards simultaneously by turning them over.
- People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
- Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the “consensus vote”, although the Moderator can negotiate the consensus.
- To ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.
The cards are numbered as they are to account for the fact that the longer an estimate is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to reconsider and either work through that some of the perceived uncertainty does not exist and play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.
Writing Acceptance criteria is key to making sure the ticket/issue is understood from everyone who will be involved from Product owner to QA Tester, Acceptance criteria define the boundaries of a user story.
A user story, its a description of an objective a person should be able to achieve when using your website/application/software, written in the following format
As an [actor] I want [action] so that [achievement]
A nice piece from Ron Jeffries wrote about the Three C’s of a user story:
- Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
- Conversation – details behind the story come out through conversations with the Product Owner
- Confirmation – acceptance tests confirm the story is finished and working as intended.
Using Acceptance Criteria as part of the user stories have many possessives on the project:
- they get the team to think through how a feature or piece of functionality will work from the user’s perspective
- they remove ambiguity from requirements
- they form the tests that will confirm that a feature or piece of functionality is working and complete.
Who in include
When holding a grooming session it’s very important to have all the right people invited and present so any questions can be answered and disused within the session.
It’s important to to make sure you have the designer to be able to answer any questions and maybe discuss possible changes.
The development team is a must as they are the one’s who will put the estimate together and ask the questions needed at this stage, along with the Dev’s its also key to have the testers in as they will help write the Acceptance Criteria and need to make sure the full understand the ticket as they will be testing it once it have been built and reviewed.
Also it’s very handy to have the account manager’s in these meetings as they can clear up any questions on the task and maybe add some background to the work so everyone can make sure the correct solution is being built from the start.