Tuesday, March 13, 2012

Scrum planning meeting: because everything is created twice

"Good plans shape good decisions. That's why good planning helps to make elusive dreams come true."- Lester Robert Bittel
    With Scrum and at the beginning of each sprint, the team, scrum Master , product owner and may be some of the stakeholders (expert ,clients representative ..) are invited to attend a time boxed meeting where we are going to discuss and negotiate the scope of the current sprint .The goal is to create a blueprint and develop construction plans before any code is produced : the first creation. Indeed the goal of the scrum planning meeting is to try to get a very clear sense of what the team is going to commit to during the sprint ,if we want a drag and drop or a simple table view ,if we want a synchronous or asynchronous functions calls … .We work with our imagination and visualization to create and get a very clear image of what we want to accomplish at the end of the sprint ,thus to share a transversal vision among all the team before the second creation or the physical creation where the code get typed take place, in order to prevent expensive changes that may increase the cost of failure over the implementation process.

   During this meeting the product owner describes the highest priority stories to the team. Some questions and negotiation may follow to limit the scope of what is going to be taken to the sprint backlog, the team subsequently discusses the committed to stories and how the implementation will be built (conception, just-in-time design...).The presence of the product owner is important at this part even if he is not directly involved, since further questions and clarification asked by the team may help them taking better technical decision and making better decomposition of the stories into tasks. The tasks are then estimated and each team member chooses what he will be committed to .The velocity input from past stories allows the team to make a realistic commitment to the scope of the work being defined to prevent demotivation coming from the “unrealistic initial estimation” excuse.

   At the end, an explicit agreement from the team on the sprint backlog is made, and the product backlog, release and sprint burndown charts are updated.