Planning
When planning the sprint the Product Owner presents the top items from the back log. The team will then break the items into tasks. During this phase the Product Owner may try to persuade the team to accept more items by manipulating the team's estimates. If the team and the Scrum Master is not able to put their feet down the team will either fail tasks or have to adjust the acceptance criteria of the items during the sprint. The latter is actually the worst because it may be hard to communicate the adjustment properly to the stakeholders.
This leads to another plausible flaw; the planning phase should clearly state the acceptance criteria of any given item. These should be measurable and not based on gut feeling. This must be specified by the Product Owner - not the team. Often the Product Owner is a busy person, who may have a lot of other things to do. Therefore the acceptance criteria may not be prepared for the planning phase. In fact the description of the item may not even be ready for the planning phase. The team is often willing to commit to the items anyway. But they should not.
Now the team start to estimate. This could be done in many different ways - planning poker is one. During the estimation the team must agree on how much effort each task should take. The problem is that team members are not equally skilled - so the effort may vary depending on which developer completes the task. If you use a mean of measurement that requires a baseline item or task to determine effort required by other tasks, make sure that all team members agree on that baseline.
Now the team start to estimate. This could be done in many different ways - planning poker is one. During the estimation the team must agree on how much effort each task should take. The problem is that team members are not equally skilled - so the effort may vary depending on which developer completes the task. If you use a mean of measurement that requires a baseline item or task to determine effort required by other tasks, make sure that all team members agree on that baseline.
Due to the fact that the team will be interrupted by the outside world during the sprint it is common to try to determine the hours each member will be working effectively on sprint tasks. But is this number of hours constant? If not the team may end up with either too many or too few tasks in any given sprint.
Development
During the development phase the tasks are processed by the team. A common thing occurring during sprints is unforeseen challenges such as support and bug fixing. It is naive to think that the team could be completely shielded from the outside world. As the team will start working on unforeseen tasks, it will get behind schedule on the planned tasks. At this point the team members may start to wonder why they spent so much time on estimating tasks in order to fill the sprint log (especially if they accepted too many tasks).
Another issue is focus. It is important that the team keeps focus on the tasks in the sprint and on the acceptance criteria of each task to avoid the feature creep.
Another issue is focus. It is important that the team keeps focus on the tasks in the sprint and on the acceptance criteria of each task to avoid the feature creep.
Evaluation
After the development phase is completed it is time to evaluate the output of the sprint and consider how to improve the process.
The output should be evaluated by demonstrating that the item produced meets the acceptance criteria. If the Product Owner accepts a item, which does not meet its acceptance criteria the acceptance criteria becomes less important - or even diluted.
If the Product Owner is a busy person and therefore did not produce any good descriptions (and acceptance criteria) for the items, the team may demand that the Product Owner improves these for the next sprint planning. However, if the Product Owner is satisfied with the completed tasks, (s)he may no take the request too seriously.
It is important to react on improvement requests, to agree on how to get better and to follow up on these agreements. Otherwise the team will realise that requesting improvements does not lead to anything but talk and the process will not get any better. This is pure toxic for the Scrum process.
The output should be evaluated by demonstrating that the item produced meets the acceptance criteria. If the Product Owner accepts a item, which does not meet its acceptance criteria the acceptance criteria becomes less important - or even diluted.
If the Product Owner is a busy person and therefore did not produce any good descriptions (and acceptance criteria) for the items, the team may demand that the Product Owner improves these for the next sprint planning. However, if the Product Owner is satisfied with the completed tasks, (s)he may no take the request too seriously.
It is important to react on improvement requests, to agree on how to get better and to follow up on these agreements. Otherwise the team will realise that requesting improvements does not lead to anything but talk and the process will not get any better. This is pure toxic for the Scrum process.
What to do
If you are going to use Scrum as your development process please take it seriously. Let people know when they fail to do so. Otherwise you are better off choosing another process that match the way you want to work.
