Explore the use of Story Points

[tschaffter]

Motivations:

• Continuously train us to estimate the time required to develop a feature.
• Ensure that team members are not overloaded.
• Better prioritization of backlog tasks.

Note

The Challenge Registry Team is a small team that has 3-4 developers with different FTE available. The goal of this ticket is to explore whether Story Points could positively contribute to our development workflow. For our team to adopt SP, their benefits should (largely) outweighs their cost.

The discussion will be timeboxed to the second half of August / before the start of Aerilynn (intern).

Tasks

• Read Atlassian: Story points and estimation
• Watch Learn Agile Estimation : Story Points Estimation

[tschaffter]

Added to Sprint 22.08.

[tschaffter]

Atlassian: Story points and estimation

Agile estimation is just that: an estimate. Not a blood-oath.

Agile estimation is a team sport. For example, if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.

Unfortunately, story points are often misused. Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity. Instead, teams should use story points to understand the size of the work and the prioritization of the work. For an in-depth discussion on story points and estimation practices, check out this roundtable with industry experts, and read on for more agile estimation tips.

Teams starting out with story points use an exercise called planning poker. At Atlassian, planning poker is a common practice across the company. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just couple minutes) to understand the rationale behind different estimates. Remember though, estimation should be a high level activity. If the team is too far into the weeds, take a breath, and up-level the discussion.

There's actually an Planning Poker app!

No individual task should be more than 16 hours of work. (If you're using story points, you may decide that, say, 20 points is the upper limit.) It’s simply too hard to estimate individual work items larger than that with a high degree of confidence. And that confidence is especially important for items at the top of the backlog. When something is estimated above your team's 16-hour (or 20-point) threshold, that's a signal to break it down into more granular pieces and re-estimate.

Retrospectives are a time for the team to incorporate insights from past iterations–including the accuracy of their estimates. Try, for example, pulling up the last 5 user stories the team delivered with the story point value 8. Discuss whether each of those work items had a similar level of effort. If not, discuss why.

[tschaffter]

Moving to Spring 23.01

[tschaffter]

Done