What Does “Done” Really Mean?

The definition of done is one of those things that drives businesses crazy.

During waterfall projects, the following definitions of done often get thrown around:

  • Developers define something as done when they have completed the development phase of a project.
  • Testers define something as done when they have tested the software and it passed all test cases.
  • Validation/QA users define something as done when all the required paperwork is completed.
  • Project managers define something as done when the client approves the deliverable.

How do we define “done” for agile projects?

Since scrum is more of an iterative process that requires all team members to complete their work during a given sprint, done means a combination of the above criteria.

For a given sprint, done means:

  • All code has been written and checked in
  • All features have been validated by the testers
  • All features have been approved by the Product Owner

In essence, this means that a sprint is done when the product is ready for your end-users. This is one of the main benefits of scrum and agile development: once you complete each sprint you have a shippable product that you can release to your end-users. This allows you to deliver value to your clients more often and more effectively.

How to become a great product owner

What is a product owner?

A product owner is the Scrum role responsible for representing the interests of the end-users of a given product. This role is often filled by the product manager of a given product, but can also be filled by other stakeholders or even a project manager.

What does a product owner do during a Scrum project?

  • At the beginning of each sprint, the product owner is responsible for providing the product backlog (list of desired features/functionality) to the Scrum team.
  • During the sprint, the product owner is responsible for providing clarity to the Scrum team when questions arise
  • During the sprint, the product owner is responsible for ensuring that no additional features get added to the sprint backlog.
  • At the end of each sprint, the product owner is responsible for reviewing and rejecting/approving the deliverables.

What makes a great product owner?

  • Knowledge of what the customer needs/wants
  • Basic knowledge of how software is developed
  • Ability to manage all project stakeholders
    Why aren’t there more great product owners?

Many people placed in the product owner don’t succeed for the following reasons:

  • They are not the true owner of the product (features or profitability)
  • They are not familiar with the Scrum process
  • They are not able to dedicate enough time to the project


In conclusion, all successful Scrum projects have a product owner who understands the product and can commit adequate time to the project. If you are going to be a product owner, make sure you research what your customers need and how it will impact the bottom line of your company.

What is Planning Poker?

What is it?

Planning poker is a group estimation tool that is used to help the project team come to agreement on task duration estimates.

When should I use it?

Planning poker is performed during the Spring Planning Session at the beginning of each sprint.

What are the inputs for planning poker?

In order to play planning poker, the team must have the list of features to be delivered and a deck of planning poker playing cards.

What makes planning poker cards unique?

Instead of having values ranging from 2 through Ace, planning poker cards have values that are more conducive to estimating task durations. Typically these values are: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. These values correspond to the number of days a feature would take to develop.

Who attends a planning poker session?

Planning poker sessions usually are attended by a moderator, the product owner, and the development team.

What is the process?

  1. The moderator reads the description of the user story/feature the team is estimating. The product owner may provide clarification on the feature.
  2. Each estimator chooses a card from their deck that corresponds with their initial estimate of the development effort. Each estimator places their card upside down on the table so that they do not influence the other estimators.
  3. After all estimates are on the table, the cards are flipped over.
  4. If there is a significant range between estimates, the estimators who submitted the high and low estimates provide rationale on their estimate.
  5. Once the discussion on the range has been conducted, steps 2 through 4 are repeated until a consensus is reached.

What is the main benefit?

Planning poker’s main benefit is that is encourages open discussion about estimates. This helps the team reach a more accurate decision instead of relying on the opinion of one influential team member. It also allows the team to take advantage of the experience of all team members.

Where can I get the cards?

Planning poker cards can be purchased or made from scratch. Below are some links for procuring your own planning poker cards:

Sprint Retrospectives

The Sprint Retrospective is one of the most valuable tools in the scrum arsenal. The retrospective is designed to help the team improve their processes and performance so that future sprints are even more successful than the one the team just completed. Implementing and embracing Sprint Retrospectives is a key to project success and improving the overall performance of your team. Below are common questions I have received about sprint retrospectives.

When does the meeting occur?

  • At the end of each Sprint
    • After the Sprint Review (demo) meeting with the Product Owner
    • Before planning the next Sprint

How long should the meeting last?

  • Most scrum practitioners suggest that you timebox the sprint retrospective to three hours.

Who attends the sprint retrospective meeting?

  • The Scrummaster
  • The Team

(note that the Product Owner does not attend the meeting)

What is the purpose of the meeting?

The team evaluates how the sprint went and suggests improvements to their process so that future sprints are even more successful.

What makes a Sprint Retrospective successful?

  • All team members must feel comfortable providing feedback
  • All aspects of the Sprint should be analyzed
    • Tools used for development
    • Tools used for communication
    • Team composition
    • Project logistics
  • The sprint review must result in actionable items that will be implemented during the next Sprint.

Building the ideal war room

In a previous post, we discussed the benefits of colocation to a scrum development team. Now that we have established why you want a war/team room, let’s dive into what your war room should entail.

A war room provides the following:

  • a dedicated location where the team can work
  • a location that is isolated from others within the business to reduce distractions

A war room has the following:

  • Plenty of wallspace to hold whiteboards, corkboards, and other collaborative tools
  • Plenty of electrical outlets to support all the computers, monitors and other electronic equipment
  • Appropriate lighting (harsh fluorescent light is not ideal)
  • Storage space for personal belongings (since team members will not have cubes to store their gear in)
  • Small refrigerator to store soda or other beverages (reduces the need for runs to the kitchen or conveniene store)
  • Appropriate temperature controls

A war room does not have the following:

  • Walls or cubicles separating the team members
  • Adjoining noisy neighbors or busy hallways

Those are the basics of what a war room should entail. If you have features that have worked well in your experience please leave a comment so that others may benefit.

Conducting a Sprint Review

Once the team has completed the development phase of the sprint, the next step is to conduct a Sprint Review.

What is a Sprint Review?

A Sprint Review is a demonstration of the new functionality to all project stakeholders. The meeting serves to alert stakeholders of the progress made in the sprint and to set the stage for the next sprint.

Who attends the Sprint Review?

The Sprint Review meeting is attended by the project stakeholders. These stakeholders include the:

  • Product Owner
  • Project Team
  • ScrumMaster
  • Executive Sponsors (if applicable)
  • Customers (if applicable)

Why conduct a Sprint Review?

The Sprint Review meeting is important because it allows you to follow one of the core principles of scrum – continuous feedback and iterative improvement. The Sprint Review meeting allows you to receive feedback on the functionality that was just developed. This helps you to ensure that you are on the correct path, or to help you get back on the right path if you were heading in the wrong direction.

What is the structure of the meeting?

A Sprint Review meeting is informal in nature. Teams should aim to not use a PowerPoint presentation. The meeting is designed to stimulate conversation and PowerPoint slide decks often serve to stifle dialogue. Instead, the team should converse with the stakeholders in an attempt to engage.

How long should the meeting last?

The meeting duration should correspond to the amount of functionality that was developed. In general, these meetings should not exceed an hour in length, and they often are as short as 10 minutes.

Who demos the functionality?

Do not feel obliged to have the ScrumMaster present the functionality every meeting. Anyone on the team is encouraged to give the demonstration.

Top Scrum Practitioners on Twitter

As social media become more and more important to the lives of agile project managers and scrum masters, I thought I would provide you with a list of scrum subject matter experts to follow on Twitter. Click on the links below to explore their Twitter profiles. My profile can be viewed at http://twitter.com/cmcspiritt.

If you have any others you think I should include in the list, please let me know.


One of the main themes of Scrum is the belief that project teams should be colocated. This belief is based on the idea that teams communicate better when they are colocated. We can all attest to this from experience in our own lives. Ever been on a call where one team member states something and everyone else seems to have no idea what they are talking about? While there may be several reasons for the confusion, one contributing factor is the lack of face-to-face communication.

When you are forced to communicate via other methods you lose the benefits of in-person communication. These benefits are:

  • The presence of non-verbal context clues (gestures, facial expressions, etc.) on the part of both the speaker and the listener
  • Presence of conversation/dialogue (other methods of communication tend to be more one-way)

You may think that simply having all your team members in the same building is sufficient in terms of colocation. While this is an improvement over teams being separated by thousands of miles due to the ability to schedule face-to-face meetings, it is still not ideal from a scrum vantage point.

Scrum preaches the benefits of having a Team Room. This room allows your team to be situated in a common area and benefit from the close proximity to teammates (brainstorming, collaboration, etc.). It also serves as the team headquarters and provides a place to post all the project artifacts. When team members are surrounded by their colleagues they have the opportunity to be more consultative to each other and to self-organize/manage themselves.  Also, having a team room makes conducting the daily scrum much easier due to obvious factors (everyone is already together). In later posts, we will talk about the key features of a Team Room.

So in conclusion, when at all possible you should try to insist that your project team is colocated. It will make things easier for you and the team.

Scrum Documentation

Many people feel that scrum means that they don’t have to document the project anymore. That is simply not the case. The reality is that the type of documentation required for scrum is significantly different than the type required for a waterfall-driven project.

Below is an overview of the types of documentation that a scrum project requires.

Product Backlog

    • Describes “what” will be built
    • Managed by product owner
    • Translated requirements into user stories
      • User stories = one or two sentences in language of customer
    • Contains rough estimates (in days)
    • Contains priorities, reprioritized after each sprint

    Sprint Backlog

      • Produced from Spring Planning Meeting
      • Tasks can be of the following types:
        • Design tasks
        • Coding tasks
        • Testing tasks
        • Documentation tasks
      • Tasks are not assigned, but signed up for
        • Each person is working on one task at a time
        • Estimate of the task adjusted daily
      • Tasks cannot be added, but can be removed if out of time
        • Velocity will be established over iterations
          • # of tasks that the team can complete in one sprint

      Sprint Burn-down Chart

        • Shows the number of hours of work left to satisfy all the requirements of the sprint

        Scrum Process

        Below is a high-level overview of the process that occur during a scrum project.

        Sprint Planning Meeting

        • Timeboxed at 4 hours
        • eam negotiates with product owner over what to put in sprint
        • Determine the sprint goal (specific, measurable, demonstrable)
          • E.g. make the application run on SQL server in addition to Oracle.
        • Translate user stories into “how” a requirements is to be built
        • Estimation
        • Estimate in ideal days
        • Play planning poker
          • Each team member gets a deck of playing cards
          • Put down the card for the number of days a user story would require in development time
          • If a user story takes too long, break it down into sub-stories
          • All team members show cards at same time
          • Discuss discrepancies to arrive at agreed upon duratio

        Daily Scrum Meetings

        • No more than 15 minutes in length
        • Traditionally a stand-up meeting
        • Not for problem solving
          • Whole world is invited
          • Only team members, Scrum Master, and product owner can talk
        • Each team member answer 3 questions(signify commitment in front of team)
          • What did you do yesterday?
          • What are you going to do today?
          • What is in your way?

        The Sprint Review

        • Team presents what it accomplished during the sprint
          • Typically takes the form of a demo of new features or underlying architecture
          • Informal meeting
            • 2 hour prep time limit
            • No slides allowed
          • Whole team participates
          • Invite all stakeholders

        Sprint retrospective

        • Performed after every sprint
        • Evaluate what is and is not working
          • Discuss what the team would like to:
            • Start doing
            • Stop doing
            • Continue doing
        • Typically 15-30 minutes
        • Whole team participates
          • Scrum Master
          • Product Owner
          • Team
          • Possibly stakeholders