Versions Compared

Old Version 1

changes.mady.by.user Gildas Lanilis Gmail

Saved on

compared with

New Version Current

changes.mady.by.user Gildas Lanilis Gmail

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add link to poker planning

Let's face the reality and be honest with ourself, Engineers are bad at estimating.

Engineers are bad are answering the question "How much time do you need to develop this item?". The answer depends on multiple factors that I don't want to discuss here. Literature is full of examples.

However, Engineers are good at comparing things. Engineers are quite confident into saying: "This item looks twice bigger than this one."

In the Agile community, the best practice to provide estimate is to use the Planning Poker with Fibonacci numbers (1, 2, 3, 5, 8, 13, 21, 34, 55, infinite).

The key point in Planning Poker is that it is a consensus-based approach that trigger discussions within the team. 

Materials: Poker card game or set of post-it numbered (1, 2, 3, 5, 8, 13, 21, 34, 55, infinite). Each team member must have a Poker card game.

Tip
titleTips
  • Do enter in JIRA the Story Estimate prior to click on "Start Sprint" button. Otherwise, your burndown chart will be skewed.
  • You can find on Internet, tons a Scrum Planning Poker card. Mine are simply Post-it, and it works very well.
  • ONAP Poker Planning Training Materials

High level approach:

  1. Scrum Master asks the PTL to present the story
  2. PTL presents simply (in non technical term) the story to the team
  3. Team may ask questions to clarify
  4. The Scrum Master asks the team to vote by using a Planning Poker Card
  5. At the same time, all members (but PTL and Scrum Master) display ONE card
  6. Most of the time, team member don't have same result. That is OK.
    1. Scrum Master asks the team member with lowest estimate number to elaborate his/her thoughts (He/she may have a good idea to address the story quickly).
    2. Scrum Master asks the team member with the highest estimate number to elaborate his/her thoughts (He/she may have consider other difficulty to address the issue).
    3. There is no Right or Wrong answer. Again the key point is to have discussion within the team
  7. Once the Lowest and Highest Team member have explained this reasoning, the Scrum Master asks again ALL team member to vote
  8. The process in steps 5, 6 and 7 must be repeated until the team reach a consensus
  9. The team must proceed with the TOP Backlog item until they believe the Sprint is full
  10. The Scrum Master records the estimate in JIRA (Estimate field on right side below)
    Entering Estimate

Notes:


  1. It may take a 2-3 iterations for the team to know how much they can deliver with a Sprint
  2. If some backlog item are not addressed with one sprint, it is the responsibility of the PTL to determine its new priority (either to next spring or down to the Product Backlog)
  3. There is no value in comparing estimates made by different team. As every team is unique, estimate are also unique
  4. If estimates are big (equal or larger than 21), then the Backlog item must be broken down into smaller piece
  5. A Backlog item with an Infinite estimate requires rework by the PTL
  6. The role of the Scrum Master is to ensure the process is well understood and runs smoothly