Story Pointing

It all rather depends upon whether or not the Sprint Goal was met. How many other stories were planned in and actioned, and was the increment accepted by the Product Owner for potential release?

If a dozen other stories were progressed broadly in line with their estimates and if they satisfied the Sprint Goal, then you may not have too much of a problem. Was the planned work completed and accepted early, and were those three 8 pointers then brought forward into the Sprint? As Mike Cohn blogged last week, undone work is not necessarily evil in such cases.

If the Sprint Goal was not achieved, or if those were the only 3 stories inducted into the Sprint, then there are deeper issues. The questions you are asking should be posed to the Scrum Team no later than the next Retrospective. What are their thoughts on the process they own and follow, and how do they think it might be improved?

I would suggest that you need to baseline.

Typically we pick a single story that took an average amount of time and c all that 5 story points. We can then assess each new story as being more or less effort than that baseline.

Have you tried this?

If you have and you are still getting such a large standard deviation between your stories then it is likely that there is not enough time spent in refining the backlog. Maybe your stories are too ill defined to even take a guess. Try turning all of your acceptance criteria into actionable tests. I prefer to create 'Given->When->Then' statements for all of my test cases initially and as part of the refinement sessions. This will take more time and you will not need to do it forever however it can help your team members better understand what goes into the make-up of their stories and thus the effort in delivering them.

-MrHinsh

There were other stories included in the sprint. Except for the one that could be completed, they were all approved at the review. My concern arises from the fact that though they do manage most times to finish what they pick up, there's usually a mad rush at the end of the sprint. And as a result, QA becomes a bottleneck, with the developers having to pitch in. This is not something they are happy doing on a regular basis.
I am definitely going to be raising this topic at the retrospective later today. At present we only have a technical option as a low level baseline for 2 points.
We have recently increased our grooming sessions as well. So it will be interesting to see how the next sprint goes.

The team does not wait to complete the planned work before taking in more stories if they feel they are on track to complete everything. One of the reasons for failure sometimes. When a developer finishes one story, instead of jumping to another one in the backlog, would it b worthwhile to pair program with another developer, finish that other story quicker to send through to QA before picking up a new one? Will reduce extra time set aside 4 peer review as well. What do you think?

I think this is a good indication that stories of size 8 are really too large for the team. There are too many uncertainties and unknowns for the team to be able to predict the effort. The whole point of storypointing is for planning purposes and if you can't use the numbers for planning. Try to break stories down further, e.g. for a sprint suggest that you only include stories with a max size of 5 and see what happens. This will likely also create a better flow of stories from start to finish which will allow for testing to start earlier.
Generally it is much easier to start something new than to finish what is started, especially if the remaining tasks of a story is some kind of testing or documentation. Ultimately this is something that the team need to collaborate on and figure out. As a SM you can ask questions like, what can we complete today? to help focus on things thare are in progress.

We had an interesting planning session yesterday. After we scored each story, we wrote out tasks for it with hours plotted against the tasks. As we put the post-its up we realized that there was a vast gulf between 2 stories that had been scored the same number of points. We had to re-score again.
We do not have the luxury of choosing whatever story/size we want. At the most, our backlog contains items of about a sprint and a half ahead. They are prioritized and not all stories can be broken down further, unfortunately.

OK, so you found several things to improve:
1. Relative estimating. When estimating the 2 stories, obviously the team didn't see the whole complexity of one story. Try to ask why. Was the story detailed enough?
2. Release planning. Try to plan about 3 sprints ahead in your Product Backlog. If you do that, the flexibility of choosing whatever story you want will not seem as luxury any more.
3. If you still have a high priority story which is too big for a sprint and cannot be broken down, break it down. It sounds crazy, but I have worked with a team which had the same situation. They stated it is not possible to break it down, planned it, failed to deliver it, and after the sprint they wanted to break it down in order to plan only the remaining effort into the next sprint. So it was suddenly possible to break it down.