SE-2800 Software Engineering Process
Estimating Story Points using Planning Poker

Outcomes

• learn to groom a Product Backlog in order to
  • prioritize PBI's according to importance (according to the Product Owner's assessment of the most important features)
  • refine (add details to) PBI's using iterative application of the INVEST principles
  • utilize Scrum Planning Poker to estimate Story Size for prioritized PBI's
  • ensure that PBI's are ready to be moved into a Sprint

Summary

In the previous lab, you used Jira to enter the tasks and their hour estimates associated with the User Stories you completed in SE2030 for the project application. The number of Story Points associated with those tasks is usually estimated BEFORE the task hour estimates are entered, but we reversed this since Story Points are a relative metric and are quite abstract until you get some experience associating Story Points with effort. Since that is the case, we arbitrarily assigned a value of 8 to the largest User Story you had task-estimated - this should give you a sense of the effort involved when you think of an 8-point PBI.

Now that you have a sense of the number of actual tasks and time you and your teams put into implementing the first stories, you are in a better position to be able to relate Story Points with effort.

In SE2800, you'll use a Story Point scale that roughly corresponds to the level of effort associated with the following examples:

• 0 - the item is already done or is so trivial (e.g. changing a class name) it doesn't warrant giving it a finite value.
• 1/2 - a tiny item - perhaps a minor defect fix, such as correcting the spelling of a UI item.
• 1,2,3 - small defects, knowledge acquisitions, or stories that might take from 1 to several hours to fix, research, or implement.
• 5,8,13 - medium stories (not defects or knowledge acquisition, unless a significant re-write or amount of research is needed). A 13 is the largest single story that could be completed within a sprint. Anything larger must be broken down into smaller stories.
• 20, 40 - significant features that would take longer than a sprint to implement
• 100 - Epics - huge sets of features (comprising an entire product release)
• infinity - obviously too big to even guess at without further detailed discussion
• ? - the defect or story under consideration needs further discussion - not enough is known about the story or defect to make sense of it or provide an estimate. More discussion is needed.
• pi - not used in SE2800, since you won't be doing day-long or multi-day spring grooming. Used to indicate a break is needed during a multi-hour planning session.

Assignment

Your team will use the planning poker game to establish the specific number of points for all un-done items you currently have in your product backlog. Your instructor has created the “games” for your team with items (User Stories, Defects, Internal Improvements, and Knowledge Acquisitions) already entered. Do not enter your own items or create additional items.

Remember: For the User Stories you implemented in SE2030, let's establish that the larger of them was an 8-point story - this gives you a starting point for estimating the remaining stories. However, remember that one or both of these stories, in addition to implementation,  required you to create use cases, high-level sequence diagrams, low-level class and sequence diagrams, and Junit tests, and this work was distributed over a few weeks (with certain other SE2030 "overhead"). You may determine that you do not need to do ALL of these things for the each of the upcoming stories - although you likely have to do some of them (e.g. UI mockups, JUnit tests).

In Confluence, create a page named “Planning Poker”. On this page, create separate sections for each item. After you play a "round", discuss your estimates as a group, and write down the main points of the discussion - particularly to the differences between the highest and lowest estimates. After discussion, you and your teammates *should* be able to reach consensus - but if not, write down the reason.

Ask your instructor for clarification of User Story details if necessary - your instructor is “product owner” for this exercise. Refer back to the full Acceptance Criteria in Jira if necessary.

After you have completed the planning poker estimations, use Jira to enter the story point values for each of these items.

Submission

You do NOT have to enter create subtasks for these items at this time.