What Commitment Means?
Commitment in the Scrum framework, means that the team makes a commitment to implement the user stories selected by the team for the next sprint and also the implementation must be in compliance with the Definition of Done. Of course the selection of the user stories came with this admission that the team should always bring the expected results.
Why it doesn't always work? What to do?
Commitment is commitment not a guarantee. So which factors make the team to commit to user stories and not fulfill that promise?
a) Underestimation - Lack of know-how
b) Underestimation - Poor definition of user stories
c) Misunderstood criteria
d) Skipping the quality part consciously
e) Skipping the quality part unconsciously
f) Trying always to increase velocity
I could add more reasons such as interruptions during the sprint but I want to focus on those which affect the team under normal circumstances and not due to failure of scrum usage.
Underestimation - Lack of know-how
If there is a technically inexperienced new team which decided to do scrum, then it is normal this team will not estimate accurately. How this can be minimized? In another article (http://succeeding-with-agile.blogspot.gr/2015/05/why-size-matters-user-story-estimation.html) I wrote about story points and how to use them having the size in mind. I mentioned that every team should define an imaginary user story which had analyzed very good in technical terms in order to define the reference story points (most of the times is number 5).
This will help the team for future estimations by comparing the new coming stories with the reference. But lets see things a little bit closer. Still the team will face user stories which the developers have no idea of what technically means and of course they will not have time to the planning meeting to go in such details. That means the cannot visualize the size at all.
In that case there is not straightforward answers but there are some possibilities. One possibility is to call for external help. Meaning that they could ask a senior developer from another team having explain first to him the imaginary reference user story and the points they assign to it. That way the senior developer may visualize the size of the current user story related to the imaginary.
Another possibility is to assign the reference points to the user story. Why? Well because the reference user story should be a story that it is not so big and not so small. An unknown user story size most of the times either is close to the reference story or bigger. Surely the team risks the fact that it can be much bigger but if we assume that the Product Owner handles the user stories properly then on top of the backlog there should be stories with reasonable size.
Finally the team could ask from the Product Owner to try to split the story to parts that still make sense for development. This is difficult in cases that the Product Owner is not a technical person and he simply sees the User Stories purely as a user. Or close to it.
Underestimation - Poor definition of user stories
Who is responsible for good user stories? The product owner of course. But, this is not true 100% because it doesn't mean that the Product should is always aware of how a user story looks in the eyes of the developers.
For that reason, in the planning meeting the team discusses the user stories in order to find almost exactly what the output will be. Not how it will be done. This is the job of the team. The truth is that during the discussion the developers are trying to agree to something they feel capable to develop without many unknown areas.
So in the end all the team (with PO) is responsible for user stories that at least cover the INVEST principle.
Independent: The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable: User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable: A user story must deliver value to the end user.
Estimable: You must always be able to estimate the size of a user story.
Small: User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable: The user story or its related description must provide the necessary information to make test development possible.
Even if a good discussion took place in the planning meeting, sometimes the team delivers a story which does something else that the defined criteria. This can happen by not writing down the refinement details of the criteria into the user story during the planning meeting. Many teams are discussing and understand the criteria but the forget to write into the story the details and the conclusions of the discussion because they feel comfortable by just by understanding it.
The problem is that when some days passes during the Sprint and the team starts the implementation, they are reading the criteria but they have forget the details they agreed during the meeting. The result probably will be to implement the user story with missing functionality.
So don't forget to write down as much as you can during the planning meeting. A good solution is to record the meetings if you are being bored while writing.
Skipping the quality part consciously
Quality in software delivered with Scrum is not negotiable but the temptation to deliver features with poor quality have proven to be unbelievably big. Why? I will not mention the case that pressure is coming from above to deliver more stories in one Sprint because this is clearly poor implementation of Scrum which says that the team should decide and commit to which user stories (starting from the top of backlog) will deliver in the next sprint. This implicitly means that the team things about also the quality must be part of that commitment.
But here sometimes things are getting weird when the Product owner suggests ways to the cut quality a little bit presenting that his is responsible for the features and he wants something not so big but something simple to deliver. So he things that the simple should have less testing. Things are messed up in that point because he says it with a focus to the phrase "don't spent to much time on it". Hmm. The team must be very careful these moments because maybe the Product Owner tries to push the team to cut quality. I'm not saying that this is always the case but they should be aware.
Another reason of cutting quality is when a user story proved to be bigger than the team thought and took more time to implement. Knowing that having the quality in place maybe they lose another user story because of the delaying in this one. So most of the times the team chooses to skip the quality part in that story in order to complete all the others. In the end possibly this story will fail in the review meeting. Even worse in the customer.
Deny any attempt to cut the quality. Internally and externally. Remember that the goal of scrum sprints are to deliver potentially shippable items and NOT a waterfall process spitted in iterations!
Skipping the quality part unconsciously
Well, this is also true because many teams does not realize what quality means. To say it better, they don't have established procedures and actions to ensure high levels of quality. Of course writing tests in various levels is the number one rule. If you don't write tests you are not producing quality software. The tests must be unit, integration, system and acceptance. This requires effort but it pays back. Not only because it helps the team find bugs early but it protects the software from inserting bugs when changing the code.
This of course requires regression to run often, most of the times in a continues integration environment. This is critical and it means that teams missing continues integration environment with test regression they produce poor quality software. Regression testing means "Refactor without fear" because if you have good code coverage with tests, the test will notify you when you change an output accidentally. Otherwise it will fail in the review or worst, as we said earlier, in the customer.
Try to establish crystal clear procedures and infrastructure to ensure quality. Discuss it with the team members and force your selves to commit on specific rules which will be visible in the definition of done.
Trying always to increase velocity
This is a very strong psychological factor which most of the times is the reason for not delivering user stories with the proper quality. Many teams thing that the velocity is something that it should be increased constantly sprint after sprint. This is wrong. The velocity should increase in the first sprints but it should remain stable afterwards. Considering of course that no people left or entered the team. The team should find the best way of working with the minimum waste along with the commitment of delivering done user stories.
Waste has a limit. So velocity has a limit. Processes that help development have a limit. So velocity has a limit. Not even overworking will not bring continues increasing velocity first of all because it has also a limit. 24 hours per day... but also the fact the overworking teams deliver less after some short period. They burnout...
Apart from that the team should leave a little space in the sprint for several reasons. First of all for unexpected events or problem in the implementation. Also teams that overload the sprint tend to work until five minutes before the review meeting doing last moment commits which are number one candidates for producing bugs! Why? Because there are not tested sufficiently and there are under the deadline pressure.
Remember that if you finish too early in the Sprint you have the choice to get something more from the backlog. Is it the same? No because if you get it in the planning meeting then all your sprint is a pressure beacon which makes the team members to fall into several mistakes of reducing quality as we said before. So try to be ahead of the schedule for half to one day.