Story Pointing stories sprints in advance
Hi all,
I'd like to get some thoughts on story pointing tickets sprints in advance. For example, let's say an epic was created with 8 stories inside of it.
- The first 5 stories that are going into the first two sprints are fully refined with detailed acceptance criteria, and because the acceptance criteria is "complete" and the team understands the scope, these 5 will be pointed by the team.
- Based on the build order, the last 3 stories are 3 to 4 sprints down the road.
- For the remaining 3 tickets, because they're relatively far down the road, we don't fully refine them right now because the acceptance criteria for those may get stale as we do more discovery with the first 5 stories. Now, because the acceptance criteria hasn't been fully fleshed out, the team is also not going to point it right now.
I've been working under the impression that the team should not point until the acceptance criteria is "complete" and the team understands and agrees on the scope of work.
Question 1: Are any of the above patterns of work incorrect, or is based off of some antipatterns?
Question 2: If nothing above is incorrect/an antipattern, how would you go about measuring burndown of a quarter/program increment (PI) of several epics if not all of them are story pointed at the beginning of the quarter/PI? The goal of the burndown would be to see, as the quarter progresses, how close we are to meeting our initial expectations.
Hello James. I think any experiment is worth existing in Agile environment, and if proven successful should be used for a benefit of the author.
Having said that personally I would be against such practice in the scrum team which I would be serving.
First of all any Scrum team should have a clear understanding that story points are not THE EXACT MEASUREMENT of anything. They aren't meters, feet, kilos pounds, km/hours, days, minutes, or megabytes
They are ABSTRACT assumptions which Scrum team assigns to the tasks. Only reason why they are numerical is that number fit into charts better compared to descriptions like "small task", "medium task" or "giant task".
hence people often fall into the trap of seeing story points as an exact physical measurement, the story points often become menace and main factor in sabotaging scrum projects(honestly I was victim of this myself).
It's because basing any REAL assumptions, forecast or plan on story points is like making a business plan for a credit based on a weather report made by grandmothers tekens without involving meteorologist, but written numerically.
Having said that, story point are used a tool by developers, in my undering Sprint planning or other events to simply estimate the items in product backlog before moving into sprint backlog and predict velocity, after that to track progress(if they choose the burn down chart instead okanvan board which is in my opinion better tool) and later to establish velocity of the team for own reference
So who is assigning the story points "in advance" in your scenario? The Sprint planning is a first event of new sprint, while assigning story points during retro and Review is counterproductive waste of time.
It can be done "in advance" at product backlog refinement, but the assign story points can be changed by developers through the discussion at the Sprint review, so what is a whole point.
I don't claim to be a top expert, here at this board, there are people with bigger experience. But that's my opinion, I hope it helps.
@Nicholas is correct. And I really like that he used the weather forecast as an example because I have used it many times myself. :)
The Scrum Guide only suggests that an attribute of "size" can be used for refining of Product Backlog Items. But it is a suggestion and not a requirement. I suggest you search for "agile no estimates" in your favorite search engine to get some insights into how many organizations work without sizing.
The following in my way of explaining Story Points. They are estimates (i.e. guesses) made at a point in time based upon the information available at the time the estimate is made. As new information is made available, the original estimate is no longer valid. Story Points are only useful for the individuals that created the estimates. How they use them is entirely up to them. I advocate that they are only useful until work begins because at that point any change you would make is based upon actual work and they no longer are estimates and become actuals. Estimates and Actuals are two completely different things and are not comparable.
If the Developers, who are the ones that should be making the estimates, feel that estimating ahead of time is useful, then who are we to say it is wrong? I would, however, encourage them to revisit the estimates prior to work beginning to determine if they have any new information that can influence their original estimates. Then stress that once works begins, those estimates are worthless for anything and should no longer be used.
BTW, this post by Ron Jeffries (who is said to be the creator of Story Points) is very informative on how Story Points came to be. The current practice of using numbers from a modified Fibonacci sequence is used because it gradually increments. This helps because distinguishing the difference between a 5 or a 6 is much more difficult than distinguishing between a 5 and an 8. True, they do work better in graphs and charts as numbers but you can just as easily use "grapes, tomatoes, grapefruit, watermelons" or "pond, lake, ocean".
For the remaining 3 tickets, because they're relatively far down the road, we don't fully refine them right now because the acceptance criteria for those may get stale as we do more discovery with the first 5 stories
Think of it the other way round. If the team's understanding of a requirement doesn't get stale, they have a problem. Emergence is to be expected and embraced in Scrum.