Reference story should be 8 points in Planning Poker

When estimation in agile teams, the effort is often estimated in Story points. To make this work, the members in estimation team need to agree on the size of a Story point.  This can be achieved by identifying a Reference story, a user story that all team members have common understanding its effort, risks, and complexity.

I have given a few estimation seminars internally within Tieto the last months.  During the development of the training modules we used expertise from Magne Jorgensen, Simula Lab in Oslo. Magne’s research area is cost and effort estimation for software development. I learned from Magne that people will produce better estimates if they relate to some other known reference task that is medium/large than if the relate to a small reference task.

There is research by Magne with empirical studies that shows this. See below.

In the agile community, it is often recommended to identify a reference story to be 2 story points. All other user stories are then estimated relative to that reference story. E.g. a user story seems to be about 4 times as much work as the reference story. This would give 8 story points estimate.

I instead recommend teams to identify a medium/large reference story and give that 8 story points. The subsequent user stories will then be weighted against something a bit larger. There is a big advantage of this: Most estimation items will be similar or smaller in size as the reference story. The result is better (more accurate) estimates.

See the research paper: Relative Estimation of Software Development Effort: It Matters With What and How You Compare. There are some other interesting results and suggestions in the paper. Definitely recommended reading if you are interested in estimations.

Photo: stromnessdundee

 

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.

 

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.

 

Interview with Jason Yip on Daily Stand-ups

My name is Henrik Larsson and I interviewing Jason Yip, Agile/Lean consultant at ThoughWorks.

Q: Jason, can you tell me a little bit about the article “It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings” and why you wrote it?

From what I recall, the initial trigger was Phillip Laplante’s article about why he hated standup meetings. When I read it, it reminded me of the dysfunctions I had been seeing in how people were doing daily stand-ups. It seems like such a simple practice and yet I was repeatedly seeing it done wrong, or at least sub-optimally. I figured it was worth trying to address this by publishing something that people could use as a reference and point others to. The article was my attempt to gather the state of the art in thinking and practice about how do stand-ups well.

Q: Why do you think Daily Stand-ups are so powerful?

At a minimum, it gets people talking to each other which is actually a big deal in many places. Beyond the minimum, a well-run standup is very effective at exposing problems. Of course, what happens after problems are detected is even more important.

Q: When did you first read or hear about stand-up meetings?

This was back in 1999 or 2000 when learning about Extreme Programming. I don’t remember exactly but it was probably the Portland Pattern Repository (i.e., the original wiki) where I first read about it.

Q: Has your view on Daily Stand-ups changed during these years?

Yes, definitely. I used to see it more about status. Then I shifted to see it more about commitment, mainly due to Mike Cohn’s writings. These days, I see it as more about problem-solving. My current preference is much more strongly toward a “walk-the-board” style of stand-up when a task / story board is available. I tend to emphasise much more the importance of focusing on completing work versus just people trying to be busy.

Having said that, there are still some aspects that haven’t changed over the years, such as the importance of keeping the ritual high-energy and being about sharing with the team versus reporting to
a leader.

Q: VersionOne just recently published the results from “State of Agile Survey 2009”. The survey shows that Daily Stand-up is the second most popular agile technique. Why do you think stand-up meetings are so popular?

Perhaps a cynical answer but I would say because it seems easy to do.

Q: What single thing do you think is most important to get right for a team using Daily Stand-up meetings? Why?

Understand why you’re doing the stand-up. You’re sharing information so that the whole team can achieve their objective. If this is not clear, then you’re really just wasting time.

Q: The classic three questions (What did?/What will?/Impediments?) is the basic agenda of Daily Stand-up meetings. Many teams are improving and customizing these meetings. Have you seen any customizations that could be beneficial for many other teams?

The “walk-the-board” style is something that many teams should consider trying. In general, have the work items (i.e., user stories) ask the questions rather than the people. What happened to the story yesterday? What is going to happen to the story today? What is impeding the story from progressing?

The Daily Scrum Meeting is the primary meeting for team members (chickens) in Scrum. Do you think that this technique could successfully be used outside the software development community? Where and how?

Short, daily meetings are already used outside the software development community. For example, most Lean environments have been using them before the concept became popular in software development
circles. I don’t see anything particularly software development specific about daily stand-ups.