Successful Sprint Reviews: The Greatest Story Never Told

By Bob Schatz

Many of us in the agile community hold a number of things sacred when we are helping others adopt Scrum successfully. I have many of them as I see the intrinsic value of each part as a key to the whole. One of these critical parts is the sprint review. As Ken Schwaber has written previously, “The sprint review is not a presentation, as we have come to know them, nor is it a time of judgment. Some of this is simply learned behavior from our past lives in dreaded project reviews. The applause that we hear is a human reaction of approval.” I have heard this applause in early sprint reviews for new teams—a sense of shock and awe at seeing working software so early.

I have observed and participated in a great number of sprint reviews. I’ve seen some quirky things from the Scrum teams as they attempt to demonstrate the working software and artifacts they have produced in the sprint. Most of them squirm and struggle in the art of telling a story. It’s hard to break the habit of thinking only of the technology and step into the world of the person who will live with the system we build.

An Early Death

We often talk about user stories and use cases in the development of the product backlog items. We want to express features and functions in terms of the end user or system component. We also want to include a statement of a feature’s value. These elements provide the context for the technology and help bridge the communication gap between the developers and the users. These stories help everyone collaborate and discuss the experience that the software needs to provide for the person or persons interacting with it. Unfortunately, in many cases, the story dies once it is implemented, and that makes me sad.

A feature’s implementation is not the end of the story but its birth. Once a story is born it should live for the rest of the project. Its birth is the result of collaboration between the developers and the users in the backlog. It drives discussions through the development of the feature in sprint planning, proves itself as reflected in the acceptance tests, and should spring into action in the sprint review. The story can live on through the operation and maintenance of the system, giving the software a grand purpose in world.

The primary purpose of the sprint review is to demonstrate what has come to life as a result of the collaboration of ideas, to gain a common understanding, and to collect valuable feedback so we can adapt and build better software. Any other purpose is secondary and of lower value to the process. Sure, we can use it to prove how talented our Scrum teams are, to show that we can manage ourselves, to show that we can produce parts of the system early, and prove just how complex the problem we are solving is; but that is not why we do this. It is not a show that needs to be produced.

Breathe Life into Your Sprint Review

The one sure fire way to have a good sprint review is to tell a story. You develop the theme in sprint planning by stringing together backlog items and weaving a plot with the user stories. Then you implement these features, testing them based on the story. Next, you bring that story to the sprint review, giving life to the software. Use real characters and locations; make connections with people and the value that the software provides. A well-developed story will stick with people long after the sprint review.

A good sprint review story has the following components:

• A meaningful; relevant theme;
  
• A sequence of events as the user would experience them;
  
• Characters and data that is realistic—use examples and names from your user community or members of the development team;
  
• Is compelling to the people attending the review;
  
• Is relevant to the people in the review; and
  
• Is at an appropriate technical level for attendees.
  

Then we have to practice as teams to learn how to deliver these stories. Oh, you can just use the excuse that we’re all introverts, but we know this is just nonsense. We all tell stories; it’s one of the oldest forms of communications among humans worldwide. If we’re not engaged in telling the story, then why should we expect anyone else to be interested?

A Tale of Two Sprint Reviews

Here is an example to illustrate the difference between letting a story die and giving it life.

Imagine we have three Scrum teams working on a product release. Each of the teams is focused on a specific functional area of the product. For our example, we’ll use a property management system. Here are a few features that you might see on each team’s backlog:

Asset ManagementThe asset accountant should be able to create an asset record for any capital asset.The asset accountant should be able to settle costs to assets under construction.The asset accountant should be able to depreciate any asset that has been received and capitalized.

Equipment ManagementThe equipment manager should be able to create an equipment master record for any capital or non-capital asset.The system should automatically create an asset record for any capital asset.The equipment manager should be able to loan or lease equipment to other business areas.A user should be able to search for unwanted equipment to find items for re-use.

Equipment DisposalThe equipment disposal manager should be notified of all items ready for disposal.The equipment disposal manager should be able to determine if special handling is required for any item ready for disposal.The equipment disposal manager should be able to tag the item with a valid disposal method.

At the sprint review each team demonstrates the functionality they build going through the backlog items. The team describes each of the features. The users provide feedback on the pieces, which is great, but something is missing.

Now imagine that the three teams have collaborated from the beginning of the sprint and have created a theme for the sprint. Each team is working on a piece of the theme, but all are working toward a living scenario. They think about the types of users they are building software for. They consider who will be involved in the sprint reviews and they begin to write acceptance tests which use actual users’ names, office locations, and real assets that they deal with everyday. Nothing engages users more in a sprint review than seeing their own name, their office, and real world items in the demonstration.

This sprint review begins by the team telling a story as they move through the software features:

Welcome to the Sprint 4 Review. Today we are going to tell you about the day in the life of a critical asset, the Pneumatic Schwaberstopper, in our business.

The Bushwood project places an order for a large, custom-built Pneumatic Schwaberstopper to support the project’s goal to increase production output by 20 percent.  Joan Snow, the equipment manager from the Chicago office, logs into the system and chooses to create an equipment record in order to track the asset under construction.  Since Joan indicates that this item is to be capitalized, the system automatically creates a corresponding asset record for financial purposes.

As Acme Industrial Supply, the equipment contractor, reports monthly on the cost of the asset, Ted Casey, the asset accountant from New York, records these costs and settles them to the asset under construction account. The asset is delivered and the project team in Houston uses it for several years.  Later, Ryan Jessup, the equipment manager in Houston, loans the asset to another area of the business.

After another year passes, the asset is no longer needed. Ryan indicates that the asset is ready for disposal and the system notifies Amy Templeton, the equipment disposal manager. Ted Casey, the asset accountant, then completes the process of fully depreciating the asset. Amy then determines that no special handling is required and tags the item for sale at auction.

Can you imagine how much more compelling a sprint review would be with a little storytelling? Can you visualize how well the story would demonstrate the true intent and functionality of the new features?

Tell Your Story

The team should find creative ways to tell the story and demonstrate the interaction and experience with the system. What’s a key word in that sentence? Creative. Have fun with the sprint review; be enthusiastic and interested in what you’ve done. When you tell the story, try to be animated. Use gestures, hands, inflection and change of cadence in your voice and facial expressions. These elements are what bring people into your story and make them feel a part of it. This opens their minds to the reality of what they are seeing and bingo! the quality and quantity of feedback increases.

So, if you’re not getting the most of your sprint reviews don’t blame the users, stakeholders, or product owners. Get your story straight!

Post-It Revisited

By Aaron Conoly

A while ago I wrote about my experiences with Scrum and a little helper I like to call “Posty the Post-It note.” Ok, so I don’t actually call it that, but I do use the Post-It extensively when I’m scrumming.

So how has the Post-it fared in the months following my article? I’ll briefly review what has and hasn’t been working and what we’ve been doing to improve our Post-it power.

Post-it Board
The Post-it board has grown, so much so that it now consists of a 4’ x 6’ white board and a 12’ poster board. So the good news is we’re busy. The bad news is that we are often overwhelmed with the amount of upkeep the Post-it board demands. Ironically the tool we were using to help us get a handle on our workload has now increased it. Sadly, the Post-it board is no longer a place for bragging rights or high-fiving. Now it’s a constant reminder of what I’ve lovingly deemed the “pile.” However, all is not lost. After some discussions with the boss, I’ve convinced the team to only use the board for a few larger projects and to track the smaller projects through other means. We’re still practicing Scrum, but we’re working to minimize the psychological impact of our pile of Post-its.

Lesson learned: If you’re not careful, the Post-it can overwhelm you with its 20,000 friends. Manage your Post-its, and if you’re feeling besieged by bright colored paper, take a deep breath and repeat this mantra, “I’m in control, not the Post-it. You’re not the boss of me, Post-it!”

Post-it Shield
Recently, we added a dedicated ScrumMaster to our team. Essentially, he’s our department’s linebacker. No more outside distractions; if you want to get to one of our Team members, you have to go through him. So every Team member’s cube features a bright orange Post-it that reads, “NEED SOMETHING? GO SEE CHRIS!” It’s not the most subtle method, but it’s helped to drive the point home and allowed our ScrumMaster to run proper interference.

Lessons Learned: My favorite element of Scrum is the ScrumMaster. The ScrumMaster protects the Team (pretty neat, huh?), but they can’t do it alone. We use Post-its to help spread the word and shepherd people to our linebacker.

Name Tags
In theory, placing an “Oink, I’m a Pig” or “Cluck, I’m a Chicken” nametag on your colleagues is a great idea. In practice, it can have unintended consequences and result in hurt feelings. While these name tags helped to spur discussion about Scrum, they were discontinued shortly after an unfortunate incident involving a Team member telling a manager, “Hey chicken! No talking during the Daily Scrum!”

Lessons Learned: It’s important to know your role. It’s also important to continually educate coworkers on the merits of the Daily Scrum and other Scrum practices. Just remember that Scrum can be jarring for your colleagues and to be patient while you walk them through the process.

Are Post-its a regular part of your Scrum routine? If so, how?

Being an Effective Product Owner

By Roman Pichler

When I met Paul, a first-time product owner on a new project, the first thing he asked me was, “What do I really have to do and how much time will it require?” Even though Paul had attended a Scrum introduction a few weeks back, he wanted to double check his responsibilities. He was worried about the time commitment he had to make and the support he would get from his boss.

Helping product owners like Paul getting started is rather the norm for me. In most organizations that I have worked with, product owners are strapped for time, are often not aware of their responsibilities, and are unsure how they should best transition into their new role. Sadly, I have also met many product owners on Scrum projects who resembled more a business sponsor briefly stopping by at the sprint planning and review meeting or an on-site customer interacting more frequently with the team but leaving it to the ScrumMaster to guide the team.

So what is the product owner in Scrum supposed to do? The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.) In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out. I have experienced that having a strong, empowered, and present product owner is a key success factor for Scrum projects – just like a strong, empowered team is. Most projects I have come across that had product owners who were not properly available or empowered suffered, and the projects never reached their maximum velocity.

I have found three things particularly helpful for product owners: a thorough understanding of the customer needs, an active stakeholder management, and a basic knowledge of how software is developed and deployed.

Thoroughly understanding the customer needs and how the product will satisfy those needs allows the product owner to describe, prioritizes, and communicate the requirements that really matter and answer all related questions. The product owner should express what value-added is from a customer perspectives and focus the development efforts toward providing that value.

Proactive stakeholder management is particularly important in larger organizations, where the stakeholders include not only customers but also internal functions, such as production support, service or sales, as well. Taking into account and prioritizing the various interests early on and involving stakeholders regularly, for instance in form of user story writing workshops and sprint reviews, is crucial to ensuring that the software can successfully work in its target environment.

Knowing (at least roughly) how good software is developed makes it easier for the product owner to closely communicate with the team. This kind of knowledge helps product owners to better understand how the team works and how important quality and the related agile technical practices are to sustain a high velocity across releases.

This broad skill set implies that ideally, the product owner would be a hybrid: someone who is able to look outward, understanding the end customer needs, and someone who looks inward, managing the value stream that transforms the customer needs into software ready to be used by the customer. Toyota’s Chief Engineer role very much resembles such a hybrid product owner: The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s.

So what did I tell new product owner Paul? Well, I took him through the key activities a product owner has to perform on a Scrum project, from hosting estimation workshops and prepping for the sprint planning meeting to giving feedback to the team and accepting or rejecting work results in the sprint review meeting. I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available. We scheduled the first user story writing workshop with the team and stakeholders, and we set up the first effort estimation workshop. I also volunteered to talk to his manager about Scrum and to explain why it is so important for a product owner to spend enough time with the team every day and to be able to make decisions on the spot.

Being an effective product owner is not easy – nor is being a good ScrumMaster. To get started, be aware of the core responsibilities the product owner has and make sure that the product owner firmly sits in the driver’s seat – all the time.

Am I, or Am I Not, Using Scrum? That is the Question

By Melanie Silver

Agile methodologies, processes, tools, and techniques are not new to software or product development. They have been around for many years. However, as companies start seeing an increased need to improve their time to market while maintaining quality, they are looking to adopt some of these agile techniques in favor over the traditional waterfall methods. Projects in many organizations are claiming to be using agile. They may be using XP (eXtreme Programming), AD (Agile Database Techniques), AM (Agile Modeling), or any number of other agile methods. They may also be using Scrum. The question being addressed here is whether, in fact, projects are using Scrum, or picking and choosing some of the techniques and calling it Scrum.

What is Scrum?

First, let’s look at what Scrum is. According to the Agile Alliance, Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Scrum does not dictate which engineering practices must be used. However, often times you will see it combined with XP to generate the benefits of agile development with the advantages of simple implementations. Scrum, used properly, significantly increases productivity and reduces time to market while facilitating adaptive, empirical systems development.

Scrum adheres to the values as defined in the Agile Manifesto:

“Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan.”

In addition, Scrum principles are the same principles embraced by the Agile Manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

Scrum also has its own characteristics and practices:

• Three basic roles: Product Owner, ScrumMaster, and Project Team
• Product Backlog
• Sprint Backlog
• Sprint Planning Meeting
• Daily Scrum Meeting
• Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration
• Sprint Reviews
• Retrospectives

Remember, I stated earlier that Scrum uses an adaptive, empirical process for systems development. This approach demands flexibility and adaptability. Each project is different; that is why this adaptive, empirical approach can adapt to each project’s needs and provide for increased productivity and reduced time to market.

What Isn’t Scrum?

So, to the question of whether a project is, or is not, using Scrum. Let’s look at a few situations:

Scenario One:

The project decides to use Scrum to manage a software development project. Management gives approval to use Scrum but insists that the team follow the prescribed software development processes to ensure the team is doing what they are supposed to be doing.

Scenario Two:

The project decides to use Scrum to manage a non-software development project. The team is not collocated and the Product Owner doesn’t have time to prioritize the Product Backlog. The Product Owner indicates everything is top priority.

Scenario Three:

The project decides to use Scrum to manage a software development project. However, the team decides it doesn’t have time to conduct the retrospectives at the end of each iteration. They also decide to conduct the daily Scrum meeting only twice a week.

I could go on an on about project teams having to follow certain practices that are contrary to Scrum/agile methods, or skipping certain practices, or not adopting the characteristics inherent to Scrum teams. The question some are asking, are those projects still using Scrum? Is it smart to use only some of the Scrum techniques and not others? Employing and adhering to all of the techniques and characteristics of Scrum provides the synergy necessary to produce optimal results. Why would you want to settle for less?

Abandoning some of the practices that make Scrum successful gives the naysayer more opportunities to claim Scrum doesn’t work. One would have been much better off espousing the individual techniques that were used than claiming that the Scrum methodology was applied.

Using only certain Scrum techniques and adopting only some of the Scrum characteristics may not preclude you from claiming you are agile. However, I would use this analogy to show why you cannot profess to be using true Scrum: Can you say you've made a batch of chocolate chip cookies if you leave out the chocolate chips?

Leader of the Band: Six Attributes of a Good ScrumMaster

By Mike Cohn

In my last column I asserted that in an ideal world a team would select its own ScrumMaster, but that it isn’t always practical. I promised that my next column would discuss what to look for in a potential ScrumMaster, whether the selection is being made by the team itself or by someone outside the team. In this week’s column, I present six attributes that your next ScrumMaster should demonstrate.

Responsible

In most organizations, when someone is given responsibility they are concurrently given the authority necessary for success. ScrumMasters are in a different situation. While a ScrumMaster does not assume responsibility for the success of the project—that remains with the team—a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it. A ScrumMaster takes on this responsibility without assuming any of the power that might be useful in achieving in it.

A ScrumMaster’s role is similar to that of an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone. Boston Pops conductor Keith Lockhart has said of his role, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie.” In an identical manner, a good ScrumMaster thrives on responsibility—that special type of responsibility that comes without power.

Humble

A good ScrumMaster is not in it for ego. A good ScrumMaster will take pride (often immense pride) in her achievements but the feeling will be “Look what I helped accomplish” rather than the more self-centered “Look what I accomplished.” A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting his own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.

Collaborative

A good ScrumMaster will work to ensure a collaborative culture exists within the team. The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The ScrumMaster should help create a collaborative atmosphere for the team through his words and actions. However, beyond modeling a collaborative attitude, a good ScrumMaster will establish collaboration as the team norm and will call out inappropriate behavior (if not already done by other team members).

Committed

While the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment, it does require someone in the role who is fully committed to it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as do team members.

A ScrumMaster should not end very many days with impediments raised by the team that are left unaddressed. A team’s impediment list cannot be swept clean by the end of every day because some impediments take time to remove. For example, convincing a manager to dedicate a full-time resource to the team may take a series of discussions with some time between them.

While the ScrumMaster may not be a full-time job, the ScrumMaster should plan on being the ScrumMaster for the full duration of the project. It is very disruptive for a team to change ScrumMasters in midstream.

Influential

To be successful a ScrumMaster will need to influence others both on the team and outside it. Initially, team members may need to be influenced to give Scrum a fair trial or to behave more collaboratively; later a ScrumMaster may influence a team to try new technical practices such as Test-Driven Development or pair programming. A ScrumMaster should know how to exert influence without resorting to a command-and-control “because I say so” style.

Most ScrumMasters will also be called upon to influence those outside the team. A traditional team may need to be convinced to provide a partial implementation to the Scrum team, a QA director may need to be influenced to dedicate full-time testers to the project, or a vice president may need to be convinced to try Scrum at all.

While all ScrumMasters should know how to use their personal influence, the ideal ScrumMaster will come with a degree of corporate political skill. Corporate politics is often used pejoratively; however, a ScrumMaster who knows how decisions are made in the organization, who makes them, which coalitions exist, and so on can be an asset to a team

Knowledgeable

The best ScrumMasters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.”

Are We There Yet?

By Aaron Ruhnow

I am the technical lead (and now also ScrumMaster) on a development team that spent most of 2006 implementing various agile practices into our daily routine. We had traditionally followed a waterfall process, so it was a little difficult at first to get the team members (and management) to digest some of the new agile methods (Two- week iterations? Developers writing tests? No Gantt charts?)—we truly were stepping through the looking glass.

With all these new practices came a lot of uncertainty. We had new tools—new to us, at least—such as FitNesse and nUnit. We had new practices, including pattern-based design, TDD, and automated builds. We had new processes and even had a strange, new rhythm. Many of us were used to being assigned a set of tasks and then spending weeks writing requirements. Some time later we would code them. (We may or may not have been involved in estimating how long these tasks would take to complete.) Making the shift to short iterations was quite a change. Having the developers themselves write up and estimate the tasks in one half- to two-day increments was also a shift, but was a bit easier to digest because the developers quickly found they could make more accurate estimates this way. It often was difficult to focus on the essentials in the midst of all of this newness.

To gain this focus, the team started to use a task board and task cards to track progress within each iteration. However, we often struggled to understand when a task, and then a story, was really done. We had learned of the “done, done, done” mantra (coded, tested, approved by the product owner), but that wasn’t specific enough for us. We needed more guidance to know when we were actually there. For instance, in our daily standups, a typical discussion would go something like this:

Dev 1: “I finished coding the ‘Copy’ function for the story.”

Dev 2: “Did you unit test it?”

Dev 1: “Uh…I think I wrote a few.”

Dev 3: “Are the Fit tests done?”

Dev 1: “Oh yeah, I forgot about Fit.”

We needed a better definition—one we could all agree on and understand.

About that time, I attended a Certified ScrumMaster class. During the class, another student mentioned that her team had a list of criteria defining done. Intrigued, I asked if she could email it to me. She told me they didn’t have it written down; it was just understood within the team. (Guess they were already in “Done Nirvana.”) After some more prodding, she did agree to write them down just for me. From her list we created the first draft of our form of done:

A story is complete when:

1. Coded/implemented
2. Peer reviewed (pair programming counts as peer review)
3. Code is run against current version in source control
4. Code is commented in source control and checked in
5. Code is commented with VB Commenter on Public/Friend methods
6. Story/use case manual test plan updated
7. Fit test written (with help of SQA person)
8. UML diagram updated
9. Unit tests written and passing
10. 90 percent code coverage achieved
11. Build and package changes are communicated to build master (i.e. introducing a new file or something)
12. Task list hours are updated and task is closed out
13. All to-do items in code are completed

We changed her list somewhat to emphasize several coding qualities that needed reinforcement within our team. During iteration planning and task generation, we now make separate task cards for steps like writing unit tests (before coding, of course), making Fit tests, and so on.

The list is still posted in our project room, but I guess we, too, have now reached “Done Nirvana” because the definition of done is now in our heads and for the most part put into individual task cards. The list now makes good wallpaper—and serves the role of looking good for managers that happen to enter our project room. I suppose it may also be helpful for newbies.

Maybe our list, as my fellow student’s did, can start your team down the path to “Done Nirvana.” But for now, this story is done.

Prepped for Success

By Roman Pichler

When was the last time you came across a project that was not urgent? I can’t remember my last time. This probably explains why many Scrum projects I have worked with were tempted to kick off the first sprint without having fully thought about the necessary prerequisites. This article discusses the minimum set of preparation activities required to ensure that your Scrum project is set up for success.

Ready …

While you want to minimize your preparation activities to start delivering shippable product increments as quickly as possible, some setup is required. If you skip the steps below to save time, you are likely to experience a lower project velocity overall.

First and foremost, the right people have to be on board and the Scrum roles have to be properly filled. That means that the product owner, the team and the ScrumMaster are available to start working on the project; the team has the right performers on the team to create shippable increments reliably; and everyone involved understands how Scrum works.

Second, the product backlog has to be initially stocked and prioritized. The product backlog should contain at least two to three sprints worth of work. For innovative, critical, or complex projects, the backlog should be as completely stocked as possible. Notice that requirements are described at different levels of granularity in Scrum, which allows the upfront requirements effort to be reduced to a minimum. Holding requirements workshops is a great way to collect requirements and to allow the product owner, team, and end customers to interact.

Third, the development and test environment must be ready. If the environments are not in place, the team cannot create shippable product increments. Remember: Every increment in Scrum must implement a subset of the requirements into software, and must be adequately documented and tested.

Fourth, the team has to know how the requirements stated in the product backlog can be transformed into shippable product increments. For a new product development project, this may entail some organized experimentation, including the creation of prototypes (spikes) and models. If more experimentation is required, the related activities should be carried out within sprints of their own right. (I will say more about applying Scrum on new product development projects in a future column.) A team working on a maintenance project typically has to read the existing documentation and explore the code base.

Steady …

Once the steps above have been completed, four more preparation activities are necessary to have a successful, short and focused sprint planning meeting. Notice that these activities tend to occur before every sprint planning throughout the entire project:

The team estimates the product backlog items. The very first effort estimation workshop is likely to last longer, as participants try to cover as many items as possible. Try to avoid workshops that last longer than four hours, though, since the concentration of the team tends to rapidly deteriorate in my experience. As part of the preparation activities for every sprint planning meeting, the team estimates any new requirements. This allows the product owner to determine whether the requirements are fine-grained enough to be transformed into a product increment within a sprint and understandable for the team or if they need be broken down and worked on further. Additionally, the team gets a preview of what’s ahead.

The product owner identifies a sprint goal and discusses the related product backlog items with the team. Remember that in Scrum, the team members have five percent of their time available to help the product owner refine requirements, discuss acceptance criteria, and estimate new requirements prior to the sprint planning meeting. If you use two-week sprints, this amounts to half a day. Having this discussion prior to the planning meeting avoids unpleasant surprises that can lead to a stressful or even unsuccessful planning meeting. Don’t forget: All meetings are time-boxed in Scrum.

The team determines its availability. This includes identifying the net hours team members have available to work on the project for the upcoming sprint.

The ScrumMaster prepares the meeting. This includes booking a suitable venue to hold the sprint planning meeting and the preparation of facilitation material required. I very much prefer planning meetings away from phones and email in properly set-up meeting rooms and the use of low-tech tools such as index cards for task identification to ensure full participation of everyone involved. Notice that the first sprint planning meeting is likely to take longer, particularly if the team is new to Scrum. Make sure that you guide the team properly and explain the sprint planning steps so everyone is on the same page. And don’t forget to keep the time!

GO!

You have set-up your project for success and you are ready to start the first sprint planning meeting now. Well done. Good luck and enjoy!