A Scrum Master’s Blog|by Mozammel Haque

Each day during our daily scrum meetings, we update the burndown chart on our Scrum boards. We prefer to do it manually, but I was looking for a burndown chart generator which will give us the initial sketch we need to get started.

I found this blog post very helpful to create our burndown charts online. Nice tool to solve a trivial problem.

You ask the team what’s most important for the product, plan your sprint accordingly, write down the stories and start your sprint!

In an idle world, you are suppose to have your prioritized product backlog ready before your sprint planning meeting. But it may happen that you have a lousy product owner who forgets to update the backlog, or may be she is sick and couldn’t work on it before your next sprint planning. What do you do now? You have different options:

• You can stop sprinting and take a day off while your product owner sorts out the backlog for the team. This can be a good break for the team as you know you can’t be sprinting all the time, then you are actually jogging instead of sprinting.
• You can take a ‘lab day’ and ask your team members to work on what they think important from previous sprint, or previous feedback from sprint review meetings. You hope that your product owner will sort out the backlog meanwhile as your team focuses on working what they think important.
• You can carry on with you planning meeting without the prioritized backlog. This works if your team has already completed couple of successful sprints and knows the direction of the product. You ask your team what they think important for the product, and form stories from their feedback. You share the planning meeting details with the product owner and give her the option to change priorities/stories as she wishes.

For one of my teams, I chose the last option and so far everything worked smoothly. The team is well into their sprint and product owner is happy after changing one story from the Sprint backlog, and replacing it with one of her higher priority one.

Our board after sprint retrospective meeting

For a team to go from good to great, it needs to look back and evaluate itself against the decisions it took and figure out how to improve on it as it carries on the development. Sprint retrospective just facilitates that and helps the team to regroup for the next upcoming sprint and get better in the process.

As we are getting matured with Scrum, we find a pattern in our retrospective meeting which matches what Henrik Kniberg says at Scrum and XP from the Trenches. We merged our way of retrospective with Henrik’s way, and found that our retrospective meetings have become a source for motivation for the team, as well as helping the team to improve.

These are the steps we currently follow during our sprint retrospective meeting:

• What we did good: We start with a positive tone and find out what was good in our last sprint, what issues we implemented from our previous sprint which we thought important for the team. We write down the points on stickies and put them in our board.
• What could be better: A nice way to find out about the ‘could be better’ ones is to ask the team what they would have done differently if they had the chance to go back to the start day of the sprint using a time machine. We list inputs from all the team members and stack them on the board along the ‘could be better’ column.
  

  Team voting on important items

• What is important to implement next sprint: This is where the whole team works together to collect items from the ‘could be better’ column and move them to ‘important’ column. After they are done, we vote on the important items. Each member of the team gets three magnetic buttons and allowed to place on any important items she chooses. She can also choose to put all her votes on a single important item if that one has such importance level.

As I’m involved with multiple teams’ retrospective meeting, one interesting observation I’ve found out that most of our teams have one common ‘important’ issue, which is “Having tech-session between teams.” So, knowledge sharing within and among the Scrum teams seems to be a common goal for our teams.