Tips for Impediment Resolution

Impediments can slow down or even halt the progress of an otherwise well-functioning Scrum team. Stefan Roock has 5 tips on impediment resolution.

Problems:

1. If the impediment backlog lives in the mysterious black book of the ScrumMaster, you have a problem.
2. If your impediment backlog does not change you have a problem.
3. If your impediment backlog is empty, you have a problem.
4. If you have an impediment backlog with a growing number of active impediments, you have a problem.
5. If the ScrumMaster resolves all impediments himself you have a problem.

Solutions:

1. Make the impediments visible
2. Search for impediments
3. Limit the number of impediments
4. Differentiate between local and global impediments
5. Help the team to resolve impediments

Please check out the blog post at Scrum Alliance for more details about the solutions.

Photo: http://www.flickr.com/photos/thepartycow / CC BY-NC-SA 2.0

 

Lifecycle of User stories

Update (Sept 20th, 2011): Added daily stand-up meeting step and corrected a few typos.

User stories have a lifecycle from their origin in a Minimum usable feature (MUF/MMF) into development to communicate product expectations between Developers and Product owner, but also for external stakeholders. The User stories also drive the development of the software product to releases of new features. A great source to learn more about User stories is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Dean Leffingwell).  Dean has also published A User Story Primer.

1. Release planning meeting: The features are structured in to initial set of user stories. This is done by the Product owner and whole or parts of Development team. The user stories are placed in the product backlog. A project map or project anatomy can be a powerful tool to show dependencies between features (and user stories) as an input to the Release planning meeting.
2. Backlog grooming meeting: Those stories not yet presented at a sprint planning meeting are revised, broken down into smaller stories, estimated, and reviewed. The acceptance criteria for the stories are discussed and example scenarios can be defined. The Development team and the Product owner participate in this meeting. This activity provides good input for the product owner’s re-ordering of items in the product backlog.
3. Stakeholders’ prioritisation meeting: The Product owner meet with external stakeholders to make the final re-prioritisations of the product backlog before the next sprint. This meeting is typically taking place only few days before start of the next sprint’s planning meeting. The product owner has input from backlog grooming activity and team progress (and impediments) from the latest daily scrum meeting (including scrum of scrum meeting). The stakeholders bring their most recent business needs and updated priorities. Stakeholders can be Product manager, Sales executive, Customer manager, Delivery manager, other Product owners, etc.
4. Sprint planning meeting: The Product owner presents an ordered product backlog with user stories. The team revise the acceptance criteria for the user stories. The Development team analyses the product backlog and commit to a subset with the highest prioritised stories, which they will complete in this sprint.
5. Start of development of story: This is done as late as possible (but not too late) during the sprint, to minimize number of stories developed in parallel. The Development team may contact the product owner for further clarification on the story. The story’s acceptance tests are written and approved by the Product owner. Some teams have found it useful have one person in the team who is the “driver” of all work tasks associated with the story. Everybody else in the team is available to complete tasks, pairing sessions, discussions, or other help to complete the story. User story driver role is rotated within the team, so for the next user story someone else will be the driver.
6. Daily stand-up meeting: The progress of completing the user story is presented for the rest of the team. If the team has adopted the User story driver role practice, this person presents all achievements and planned activities for the story. Impediments or insufficient progress may lead to changed or new tasks for the team members. This includes not only the developers, but also the Product owner and the Scrum master.
7. Story development completed: A little bit later in the sprint, the story is now designed, coded and passes all unit tests and the integration test suite. The acceptance tests for the story pass without any problems. At this point the Product owner should be contacted to accept the user story. Remember the definition of done for user stories!
8. Sprint review meeting: The whole scope of the development sprint is presented by the Development team for the Product owner and other stakeholders. The acceptance tests for user stories are run to demonstrate the new functionality in the system. The Product owner then approves the all completed stories and the sprint. Remember the definition of done for sprints!
9. Release tracking: Each completed user story contributes to the progress of one or several product features. This is monitored by the product owner to check if the release date and contents can be kept.

Please comment on your experience on the life of stories. What link in this chain is the weakest? How can we improve the flow to provide more value for users/customers?

 

When The Daily Scrum Isn’t Daily

The daily scrum is just that — daily. This synchronization point is meant to increase the team’s communication and focus. The team meets each day, discusses the day’s work, finds out who needs help an. When teams don’t huddle daily, they risk losing the communication and focus necessary to build the right product with the appropriate quality and meet their commitments.

Often this smell, moving the daily scrum to anything other than a daily meeting, is an indication that something else is awry. The underlying problem may lie with misunderstanding the purpose of the daily meeting and/or misunderstanding the discipline and simple practices that teams can and should adopt for themselves.

via CollabNet Scrum and Agile Blog » Techniques For Improving Your Daily Scrum: When The Daily Scrum Isn’t Daily.

 

Use Retrospectives to improve Collaboration

Collaboration is maybe the most important quality to Scrum teams. The core of Scrum is to maximize the collaboration between the team members, but also between the team and the Product Owner  (and the customer). This is important both small single team projects and bigger multiple team projects.

In the retrospectives the previous sprint is evaluated and improvements identified.

Don’t forget  the collaboration aspect in the sprint retrospectives. It is way too important to neglect!

• How can we improve our daily stand-ups?
• How can we get the product owner more involved in our work? How can we help him to groom the product backlog?
• How can we improve the collaboration with other teams in our project?

So, in the next retrospective, try to focus on the collaboration side.

Photo: http://www.flickr.com/photos/fncll/ / CC BY 2.0

 

Description of Daily Scrum Meeting

Mike Cohn has a good introduction to daily stand-up meetings.

By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains. The daily scrum is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

via The Daily Scrum Meeting.

 

Collaboration: Interpersonal Team Dynamics

Video about Interpersonal Team Dynamics at bnet.com:

more about “Collaboration: Interpersonal Team Dyn…“, posted with vodpod

 

Stages of group development: Forming, storming, norming and performing

The Forming – Storming – Norming – Performing is a model of group development, first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results. This model has become the basis for subsequent models.

Each team is unique and has its own strengths and weaknesses. To really work together as a team the people need to get to know each other. Tuckman’s teamwork theory is working pretty well to show what phases a team should pass to be productive. It’s important the team moves on to reach the Performing phase. Some teams may need help to reach this phase as the get stuck in storming or norming phases.

For more details read Bruce Tuckman’s Teamwork Theory: Tuckman’s Stages of Group Development.

Photo: http://www.flickr.com/photos/maxshirley/ / CC BY-NC-ND 2.0

 

Skills for Teamwork

The team is not working effectively without any effort from the individuals in the team. The people need to have certain skills to enable real teamwork. Some people have easier than others. If you got a team of experts that cannot cooperate, then you will never benefit of the of power of teamwork.

Jason Little has created a list of skills needed for teamwork:

• Active Listening
• Questioning
• Logical Argument
• Respecting
• Helping
• Sharing
• Participating

Please check out Agile Mashup » Seven Essential Teamwork Skills for descriptions of these skills.

 

Daily Scrum: Focus on Completing Things

Scrum is about achieving customer value. Each day must bring the team one step closer to their goal. They must achieve things. Stories and tasks must be completed. To get more focus on this matter the questions in Daily Scrum meetings can be adapted a little bit.

Observing this team’s daily Scrums, I noticed that they talked a lot about what they did in the past 24 hours and what they would do in the next 24. Everyone seemed busy and could account for their time. But I had a hard time connecting their busyness to the work they’d committed to do in the Sprint.

So, I suggested a slight change to the three questions that I learned from Mishkin Berteig. Instead of answering the questions, “What did you do in the last 24 hours?” and “What will you do in the next 24?,” I had the team answer the questions, “What did you complete in the last 24 hours?” and “What will you complete in the next 24?” I recommended that they point at tasks and stories on the task board while answering the questions to keep them focused on the work for the Sprint.

via One Word Can Change Your Daily Scrum | Richard Lawrence.

 

Secure effective Daily Scrum Meetings

Sometimes a Scrum meeting will take on issues that are part of the normal working process of the project, or even sit outside of the project entirely. Examples of these potential productivity wasters are:

• A few individuals drill down into the problem details and begin to resolve the issue during the meeting
• During the scrum meeting two participants discuss yesterday’s football match
• Everybody asks the project manager “What is new?”
• The scrum turns into a meeting where everyone is reporting results to the project manager
• And, yes at times participants are late for the meeting.

Andrew Mospan have written a post with tips how the  Daily Scrum Meeting can be effective.