A well managed sprint planning meeting is the answer. Well organized sprint planning meetings provides the opportunity for participatory development by discussing diverse logic for achieving the same objective, and then converging to a single logic by aggregating the best of every design view. It is in the planning meeting where the development team members get amble opportunity to learn and share. Irrespective of the duration of the sprint, a well conducted sprint planning meeting will be between 5 to 8 hours duration, which is equally divided into two halves. The first half is for understanding and estimating the size estimate (story point) and the second half is for decomposing the user stories into activities and estimating the effort required for the activities.
Common obstacles for conducting effective sprint planning meeting;
- A general belief that planning time is wasted time.
- Highly technical scrum master who likes to dictate estimates to the rest of the team.
- Lack of domain and technical knowledge of the team, which prevents them from arriving at reasonably realistic estimates.
- Lack of trust in the team.
- Product owner and scrum master roles overlap developing conflicting interests.
- Lack of requirements readiness
Prerequisites for effective sprint planning meetings
- User story availability
- Reviewed for completeness
- Acceptance tests defined and reviewed
- Teams capability measures from the previous sprints (velocity, average velocity)
- Domain knowledge of the team
- Technical capability of the team
- 5 – 8 hours dedicated slot. The scrum master / product owner should see it as an investment
- An open environment conducive for open discussions without any fear
Outputs of the sprint planning meeting
- Sprint / release burn down chart for the product owner and the senior management (Y axis – story points, X axis – duration of the sprint)
- Sprint burn down chart for the development team and the scrum master (Y axis – balance effort to complete the sprint, X-axis – duration of the sprint)
- Tracking board
The best way to experience the power of time boxing is to do sprints of 1 hour duration using a timer. The count down starts from 60, 59,58…and the pressure to complete the task planned within the one hour start building up. The pressure with pleasure. My ipod which I abandoned long time ago have found new purpose now as my timer. At the end of the day, it is not that great news. I have not done much of that useful, important work. I will improve.
A young gentleman walks into my cabin for the first time to borrow some money for his lunch, and he is a team member who did not get his salary on time. That was a very powerful message to me. Points to the challenges of a start up, and the sacrifices and sufferings behind a startup. Unfortunately it is hampering the commitment and motivational aspects of the team, which dilutes the sprint.
What is the story of your project?. What is the story of your work?. What are the stories of the users of your product?…How is the product going to change / make their stories inspiring. Can you narrate it with enthusiasm?. Only then you should write the user’s stories…else they become dull and pale…and will not deliver much value to the users. Today was a forced holiday, due to bundh (strike), and that gave me some time to introspect about my current project. Unfortunately, I am struggling to narrate the story of my project to myself convincingly. Do you have a project story for me, which can be narrated to me with enthusiasm and passion…
Writing a story is different from telling a story. If you have to tell a story to an audience and capture their attention, then it must have something in it. We can always write boring stories and send to someone, where as we cannot tell an uninspiring story successfully.
That is the learning of the day. After a long stint of coaching, today I had the opportunity to listen to a very experienced person about various aspects of software engineering. One of his catch phrase was ‘Reusability is a mindset’. That answered my dilemma of defining the reusable components. Should it be a module, a function, a template, error messages, test cases…it could be all of these and more. That is my learning for the day.