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


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


  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.


  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: / CC BY-NC-SA 2.0

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?

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.

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: / CC BY 2.0

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.

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.

Next Page »