Daily standup meeting tips

I want to share some tips for improving the daily meeting ceremony. I will start defining the three basic rules.

• Every team member report what have being done yesterday
• What are you plan to during the day
• What is blocking your task progress

First my advice is to place the daily meeting at the first hours of the work day, since we share our progress and problems so all team can support and assist any team member. Every team member should be at least 5 minutes before meeting starts, so we avoid interrupting any member report. We have a 15 min time box for this meeting as maximum if some specific issue is raised we should discuss it offline with only the persons involved (time is gold and we don't want to waste the rest of the team). 

We also must follow an order for the reports we can use the table place order starting from the right, when someone starts should say his name and briefly the working progress (percentage of the task) and when he/she expects to complete it, we must avoid being too general or detailed, when he/she finish should say something like "That's it" , "That's me" or "That would be my day" so remote people can be aware that is his turn to continue.

One good practice is to review during this meeting the task board, so we can have a clear picture of the current work progress, we can display the burn down chart and review the remaining sprint resources hours, then we can identify the people that needs more help or if it would be necessary to notify some risk in order to complete the committed user stories to stakeholders.

In my experience I think would be great to include the PO in this meeting if it is possible so he/she is committed as well with the team and known the current progress.

Hope this will be helpful for your teams. Please don't hesitate to leave your comments/questions.

Struggling with our Product Owner

I have been working for many years in many software companies and I could realized that most of them had the same issue with the Product Owners, I will list a few of them.

·  Providing not much more than a high level, ordered Backlog and availability to the team for      questions or clarification was extremely limited. 

·  User Stories were developed, but were inconsistent and refined too late—often in the middle     of the Sprint. 

·  Backlog grooming (maintenance) was inconsistently practiced, if practiced at all. 

·  The Backlogs themselves were inconsistent across teams—making organizational strategic         planning and overall progress measurement very difficult. 

·  Forward-looking release planning was nearly avoided. 

·  Little time was spent ‘connecting’ external stakeholders to the performance, efforts, and            dynamics of their teams.

Is all of the above points seems familiar in your organization?. I will give some tips for improving that issues so we can deliver a high product in schedule and budged.

I think one of the more appreciated value that PO should has is the commitment with the team itself, I know that many times PO has a lot of limited time since they have all day meetings, but when the team needs him, he always should be available to respond to it. One good practice I found for that approach was to set daily meetings that we called collaboration meetings, in that slot of time we use to take all possible advantage from our PO, like grooming the US, clarifying the acceptance criteria, demo the feature progress (Dev & QA) so in that way we receive the necessary feedback in time, so we don´t need to wait at the sprint review every end of the sprint. If this is not possible for time availability reason, we can set a different time for a couple of minutes with the PO for at least demoing and review the team´s progress, for all the rest we can send him the questions or clarifications requirement through email or im. If this really is not possible we should escalate the problem with the PO´s chief.

So the key for having a good communication and collaboration is to have our PO committed with the team, as everyone knows that at final release all team (Scrum Master, Product Owner and team members) is in play, everyone wins or everyone lose. 

Hope this can help a little in your current organization.