The most value adding ceremony

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
Advertisements

10 points for effective #scrum meetings

  1. Scrum meeting or the daily scrum is not allowed to go beyond 20 minutes in any circumstance. Every body in the team must be aware of the concept of time boxing, and the about the non negotiability of time in scrum.  All must be trained on scrum, or all in the team must have read and understood the scrum guide.
  2. Daily stand up meetings (scrum) must happen every day. If possible schedule it at the same venue and at the same time.
  3. The team members must stand in a circle, to ensure that there is no hierarchy in the team.
  4. Since it is the team’s meeting, scrum master / product owner presence is not mandatory. Very often their absence in the meeting helps.
  5. The objective of the daily scrum is to understand the status of work (sprint), so this meeting must not be used as a issue resolution meeting.
  6. Each member updates three things to the rest of the team;
    1. What did I do yesterday?
    2. What am I doing today?
    3. What are the issues I am facing, and need help.
  7. Each team member can take up to two minutes to update the status of his/her work to the rest of the team.
  8. If someone needs help to complete his / her tasks, then other team members can help (after the stand up meeting)
  9. If the scrum master’s intervention is required to sort out some of the issues, communicate that as an action item for the scrum master.
  10. Revisit point 1 about the non negotiability of time.

Time boxing work – the nano sprint

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.

IMG_0405

A young gentleman walks into my cabin for…

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.

Story tellers….

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.

Liked this video about UI design

Reusability is a mindset

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.