Here are a set of impediments, which normally gets ignored, resulting in the failure of the first sprint planning meeting itself;
- In real life, the SCRUM master is reporting to the product owner, hence becomes very submissive. This can prevent the SCRUM master from performing her roles and responsibilities. As far as possible avoid direct reporting of the SCRUM master to the Product owner. If it is inevitable, ensure that they are wearing the product owner and scrum master hats, not the Boss and Subordinate hats. A scrum coach should be able to help here.
- The product owner is not ready with the product backlog. The product backlog should have enough entries to feed into the initial few sprints, so that the first sprint planning meeting will have enough options for dependency management.
- Team should know what is story points and the poker game.
- Very often the key scarce resources like architects, GUI designers will be playing a consulting role and will be handling multiple projects at the same time. Their commitment levels to the project on hand should be ensured and should be non-negotiable.
- Very often, the theme of the first sprint is ‘Architecture’, and the ‘Consulting’ architect is a key resource during the first sprint. Ensure the availability and commitment levels. She is a ‘Pig’ and a ‘Chicken’ :-).
- Do not try to manage failure into success. The essence of scrum itself is to fail fast. If a key resource is not available during the first sprint planning meeting, please reschedule the meeting, than trying to manage 🙂
- Especially while moving from ‘Waterfall’ to ‘Agile’, there is a tendency to waterfall within agile, resulting in ‘scrum falling’. This has to be consciously avoided. Very often the ‘team’ try to create a low level design phase within a sprint. The evolutionary design concept takes time to sink in. This anxiety is normal, and dont try to manage it by creating a low level design stage, within a sprint.
- The normal managerial skills like meeting management, time management, agenda, output / outcome, participation norms are really important and do not take them for granted.
- Sometimes teams think too much about the ‘accuracy’ of estimates. Accuracy of estimates increases over a couple of sprints.
- As a product owner, before committing the release date to any stakeholder, please be aware of the number of story points / sprint and the total number of story points (at the product backlog level). These initial story points may not be very accurate, which is okay, and will get fine tuned over a couple of sprints.
- What about the team location, sprint board, stand ups …anything can go wrong (murphy’s law).
List is incomplete….will be evolving further 🙂