Perhaps one of the least well understood patterns by scrum teams is finding the right size for a story. A story is just a chunk of work. And finding the right size is about estimating the chunk of work.
And story is right size if it is something that can be worked on now within a sprint. Each team is different. For each team the right size of the story will vary. When a team can commit to a story they are starting to give you feedback that a story is getting closer to the right size. We use relative sizing to find what the right size for a story is. As the team does more work it will settle on a pattern that is just right. Finding the right size of a story is something the product owner does by listening to the team and figiruing our what the team can commit to.
If you only plan 2 stories into a sprint then story size is probably too big. If plan 50 stories into a sprint then you are probably decomposing too small. In both cases the assumption is that you have a typical 7 person scrum team. The product owner with the help of the team is trying to find the right size of a story. As the team and the product owner work together they will establish a flow of work. As the team does work for the product owner a just right size of a story will start to be preferred. Analysis will be controlled such that the stories tend to be just right. About 10 stories in a sprint is a good rule of thumb. We call this application of sizing “The Goldilocks Theorem”, Dan.
3) large 1) small 2) medium
This basic pattern of sizing work has been the corner stone for every estimating system. Names like delphi estimating or base lining are legitimate techniques but often mask the basic pattern described. People are hard wired to recognize too big, too small and just right. We simply need to leverage this innate mechanism to begin sizing stories. By leveraging this innate mechanism we will find the chunk of work that leads to “One bite at a time” and “Work from a known center”.
A placeholder story is a sign of sloppy planning