Help Card - Common Issues

There are issues that crop up regularly. It’s good to have a common response to these questions and queries.

Issue

Not all stories were completed during the sprint.

Our Response

The team takes as many stories into a sprint that it thinks is possible to complete. The effort required to complete those stories is an estimate based on the information available at the time and also based on experience.

Some stories can take longer to complete than first thought. This can be caused by miscommunication (there was ambiguity in the story), more effort was discovered once the story was in progress, the requirements changed, or just the estimation is really really hard - and only an estimate not a promise.

We track our velocity (the number of story points completed/burned), we assess how close our estimates are and look to improve our estimation in each sprint.

If there is a particularly low number of points completed in a sprint, talk to the team before speaking with the Product Owner so you understand the reasons for the shortfall and you have a good response prepared.

Issue

The Product Owner is not available for meetings.

Our Response

This needs to be flagged as a risk to the project.

The PO plays a key role in the success of a project.

If the team has questions during a meeting we need the PO available to answer those questions. Without the PO we risk blocking the team and slowing/halting the work.

If the PO is going to be unavailable then he needs to provide a deputy. That deputy needs to be given the authority to make the same decisions as the PO.

If the PO cannot provide a deputy and is unavailable for some meetings then we need to speak to them immediately because this is going to prevent us from delivering the project.

Issue

Can I just squeeze this little story in?

Our Response

Ideally, no. And there are really good reasons why it’s a bad idea. A change like that will reduce productivity, it bypasses key quality control stages such as sprint planning, and so on.

The sprint is probably only two weeks long so they will need to wait no more than that before they can prioritise it. If the “little story” is business critical then have a conversation about it.

What problem is it going to solve? What value will it deliver? Which of the other stories in the sprint does it take priority over?

We fill the sprint backlog with user stories so before we take more in we need to make room. To do that we need to drop existing stories out of the sprint.

So the short answer is, in extreme circumstances yes, you can have that new feature if you can justify it and make space for it in the backlog, and accept it will bring a productivity hit and quality risk.