Agile Buddha - Page 21 of 23 - Demystifying Agile, Getting to its Core

Scrum Product Owner Has to Kiss Lot of Frogs to Find a Prince

I, am going to draw an interesting parallel – between a fairy tale princess and a Scrum Product Owner (PO). Just as the fairy tale princess may need to kiss many frogs before she finds her prince charming; a Scrum Product Owner has to do a lot of de-cluttering of backlog to identify features that will make his product successful.

Innovations go through several attempts before light bulb moments strike. Steve Jobs said, “Innovation is not about saying yes to everything, it’s about saying NO to all but the most crucial features.”

Backlog grooming and it’s prioritization directs the team and keeps it focused. Certainly, there are different aspects you need to consider for prioritization like uncertainty, risk, dependencies, effort, releasability and value etc.

How to Use Sprint Burndown Chart in Daily Stand-up and Sprint Retrospective

by Avienaash Shiralige 1 Comment

Sprint Burndown chart and Daily Stand-up help Scrum teams in Self-Organisation. Never use Sprint burndown chart in sprint review. Sprint Burndown is inward facing, i.e it is for Scrum Team.

This chart summarise overall how team is doing? Every impediment, every challenge team faced, colloboration issues etc all get summarised in this chart. Teams need to update the tasks with time remaining in hours to get this chart. Scrum Master prints and analyses this updated Burndown before daily stand-up and brings it to the meeting.

Product Owner Role in Sprint Review(Sprint Demo)

by Avienaash Shiralige 4 Comments

Sprint Review meeting facilitates developing a successful product. Hence it is a very good avenue for scrum team to directly interact with stakeholder to get their perspective. Product Owner(PO) who is responsible for overall product should facilitate having all the stakeholders like Marketing, Sales, Senior management, End Users to the demo.

In my last post where-in I discussed about Product Owner responsibility of Accepting or Rejecting user stories as and when it gets DONE. Only accepted stories will go to Sprint Demo. Product Owner kicks-off Sprint review meeting where-in he compares product increment(accepted stories) with current sprint goal to the stakeholders.

Should Teams Go for Multiple Demos within a Sprint?

by Avienaash Shiralige 3 Comments

Many scrum teams believe and practice sprint demo as part of sprint review meeting. Because Scrum says so. Formal demo end of sprint is a minimum requirement as per scrum guide. But it is not stopping you from doing more of so.

I strongly believe in the principle that if you see value in doing something, then do it more often like testing, frequent code commits etc.

Sprint end demo should NOT be the place where you are showcasing the product for the first time to your Product Owner(PO). You Should or Must go for more informal demos all through out the sprint. Product owner should be able to see what is being built all through out the sprint rather than just end of the sprint. Ideally if your user stories are small then you should be able to finish them after very couple of days.

When is a Good Day to Start a Sprint?

by Avienaash Shiralige 4 Comments

My first reaction would be Monday! Week is just starting and definitely good day to start something new. You are right! But my suggestion would be to rather focus on sprint ending day then starting. Ending on a Friday is not I have seen worked very well for many teams.

Let’s check out few reasons for the same:

Friday being last day of the week and team is quite tired by then. Hence chances of making a mistake in rush to complete a sprint is higher
Many times last few changes go untested before Monday demo which is a high risk
I have seen team working over weekends to finish and push last minute changes to code repository. This is absolute NO, as I want my team to relax and also these changes are not known to rest of the team and it is not tested. This breaks Scrum philosophy.
Most important thing, people get freedom to take long weekends as they would not miss Sprint Review and Sprint Planning which I feel are two most important Scrum team ceremony where we want everyone on team to be there.
Lot of Public Holidays falling on Monday or Friday would not disrupt the team much.

Hence my suggestion to the team I have worked with is to go for starting mid week and ending mid week. Even if you have to stretch a bit to finish some tasks, team would not hesistate to do it during mid week and also keep in mind as per research Wednesday and Thursday are most productive days of the week too!

Teams moving to this schedule have seen reduction in defects, increase in quality of code and also quality of demo improved substantially. Above all this I have seen team being less stressed and hence better productivity.

In addition to this if teams are working in distributed agile set-up(say Product Owner is in US west coast) and team is in India, then starting sprint on Monday may pose few challenges like Product Owner being available for sprint planning on his Sunday evening!

So do consider your team set-up, how they are structured, their maturity, Product Owner & Stakeholder availability etc to see what day suits well for you. But don’t stop experimenting around this!