You are here

5 essential elements on How to effectively run Sprint reviews and plannings

Sprint review and planning sessions are essential on successful Agile projects. These meetings let  the whole team to assess all tasks performed over the past few weeks. Some project teams make them highly effective and enjoyable, on the path to motivate team to follow through easily. Others on the contrary happen to fall on complexity side; sessions break out too long and focus leans towards detailed analysis.

Some time ago with a gracious help of TCS global consultancy I had an opportunity to take part in re-designing of the web presence of one of the major banks in Holland (Due to partnership agreement I not allowed to disclose customers name). Project was quite a complex one; 

  • In total there were 4 different technologies, Drupal (my favourite) being one of them,
  • By the time I concluded my part in the project team comprised 3 different nations and cultures, each having it’s own expectancy and leadership styles.
  • Team spread over 3 different locations so all meetings were online.

Despite of these challenges our project lead impersonating the Product Owner role took great deal in making sure all meetings and workshops were concise, as short as possible and highly effective. 

What were the keys that made sprint planning and review sessions so successful?

  1. Begin with the end in mind. Exactly, habit 2 from Stephen’s R. Covey creation “7 habits of highly successful people”. What will we achieve and what will be the outcome, that was the empowering question received from the project lead. We embraced the process and creativity, over the bureaucracy and strict standards. What we expected with the “end in mind”; fully comprehensive task descriptions, clear state of the definition of DONE, agreed metrics. We made following of this principle as simple as possible - think of a task, log it in JIRA, talk to your peers, co-work on task definitions.
  2. Have a meeting before a meeting. John C Maxwell in his book “Leadership Gold” writes in detail how he has followed this paradigm in his organisations. Long meetings are exhausting, especially, if majority of time you need to listen on somebody else on the subject you don’t really master, including all technicalities. So, everyone was empowered to talk through the relevant tasks during the sprint. Also, team members conducted a series of one on one pre-review catch ups to follow through the definitions of done. Eventually, during the actual Sprint reviews all micro teams just affirmed which tasks had been finished and commented only on the tasks moving to next Sprint.
  3. Short presentations only. Team members payed attention on presenting only overviews passing detailed demos to later one one one catch ups. Indeed, we were eager to demonstrate our achievements quite vivid, in many occasions exaggerating the outcome. That was great, but did it help to make reviews better? No, for all the great team had produced it was concluded to put them on retrospective’s agenda. We separated yolk from a yellow and focused on what was relevant to a particular workshop. Peers kept their pitches up to 2 minutes maximum and were frequently censored, in a polite and supporting way, on any bids to push that limit.
  4. An end day not a final meeting. This was indeed one of the top in terms of complexity to manage. All peers before starting on the project were used to an end meeting, basically, an event marking a final stop on iteration. It created a situation when the Meeting itself was an extreme deadline. Anything not done before that would impose penalties, well, not literally, but that was the mindset. We encouraged that Sprint ended on the day and not on a particular meeting. All were empowered to use the remaining time on the day to wrap up the tasks still in progress or testing mode. That way peers were less stressed as the meeting hour approached.
  5. Agile is a process not a destination. According to Simon Sinek there are two types of companies; a) project based, b) process or how he call’s that game based. We’ll that’s for the businesses, but how on Earth that’s applicable to an Agile project. Technology leads (remember we had 4 different ones) led by example, conducting demos, scheduling workshops, constantly reviewing the code and doing pair and mob programming. Thus spreading tasks all over the Sprint rather than waiting for the last days. They were aiming for excellence not perfection. Perfection would mean push all towards the end date, excellence meant to be constantly in the progress.

I have deliberately combined both Agile and pure leadership principles to let readers at least a tiny feel on how we embraced “thinking outside of the box”. A successful Sprint, actually means; “To make the rules, first break them”. One can stick to definitions as they are on paper or choose to utilize each paragraph as a tool to aim for success, up to then to decide.

Need a help in implementing a successful Agile projects give us a shout.