I use Microsoft Office, many of my clients use large ERP packages and last week I bought a highly functional math package to do data analysis. I would describe all of these as products that are refreshed over time by major and minor releases. As an outsider, the delineation of product and release is both easily recognizable and easily describable. However once you peel back the covers and dive into the inner workings of the typical corporate IT organization (broad definition that includes development, maintenance, support, security and more), how work is grouped and described can often be much more akin to a descent through Dante’s nine circles of hell.   Recently I sat in a conference room in front of a white board and challenged a group to identify how work was grouped and how the groupings related to each other. During the discussion we choose not to discuss the portfolio level within the organization and focus on the deliver functionality. The results followed a path that looked like a simple basic hierarchy running from programs, projects to sprints . . . except for the waterfall teams that don’t do sprints. This hierarchy  was crosscut by products and releases increasing the possible complexity of any particular scenario. As work is grouped together from sprints to program into larger and larger blocks additional layers of control are need to manage risk.

In Agile the smallest grouping of work is the sprint. In a perfect world, a team would accept work into a sprint where each story was independent and intrinsically motivating. Each piece of work would be its own big picture, however that scenario is at best rare. Most people are interested in knowing that they are helping build the Golden Gate Bridge, not just the left lane of a typical bridge on-ramp. We are more motivated when we believe we are doing something big. It is rare that a unit of work being delivered by a single sprint from a single team will require any scaling.

In most organizations, a project represents a grouping of work that most easily recognized. While the concept of a project is under-pressure in some circles (we will explore concepts such #NoProjects later) I haven’t sat next to anyone on plane that doesn’t describe their work as projects whether they are in marketing, sales, accounting, consulting or software. Projects and project accounting is firmly enforced in most organization’s finance and accounting departments. As noted in Projects in Agile, almost every organization has their own definition of a project. Interestingly, I was eating dinner with a group of developers and scrum masters recently when the conversation turned to the definition of project. A sizable group decided that any discrete task could be described as project. A task had a strart and an end and was goal oriented. From a grouping perspective, projects are typically an accumulation of sprints or releases in Agile. In more classic scenarios, a project can be described as one or more release into production. Any project that is more than a single team and a single team will require scaling to afford greater foresight and planning so that the pieces fit together in a coherent whole.

The definition of a release is widely variable. Releases can be subset of a project with functionality pushed to production, test  or into some other environment. Alternately a release could be a group of whole discrete projects that are moved into an environment together. The only common thread in the use of the term release is that it represents movement. Releases, other than in very uncomplicated environments, will always require coordination between development teams and operations, business and potentially customers. The larger and more complex the release, the more planning and coordination will be required.

Programs are groups of related and often inter-related projects or releases that are organized together to achieve a common goal. By definition programs are larger than projects and can be implemented through one or a large number of releases. Because they are larger and therefore more complex, programs typically require additional techniques to ensure foresight, planning and coordination so that all stakeholders understand what is happening and their role in achieving success.

A final grouping of work is around the concept of product. Building from the Software Engineering Institute’s definition of a software product line, a simple definition of a product could a set of related functions that are managed as a whole to satisfy a specific market need. Typically a product is developed through a project or program and is maintained through releases, projects and programs. Products should have a roadmap that provides internal and external customers guidance on the features that the organization intends to develop and deliver over time. Roadmaps are typically more granular in the near term and more speculative as the time horizon recedes.

As work is grouped from smallest to largest; from sprint to program or product added effort is required to organize and coordinate work. Increased levels of planning and coordination require additional tools and techniques in addition to the basics typically found in Scrum or Extreme Programing (XP). In the Agile vernacular, the need to for additional techniques to deal with size, coordination and planning is called scaling.


Demonstrations aren’t presentations, they require bi-directional conversation.

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished during the current sprint. At root, the demo is a show and tell that provides the team with a platform to describe what has been accomplished. Demos build confidence and customer satisfaction. They can be done using a simple, repeatable process that straight forward and to the point.  By making sure the process is interactive and the material concise, all of the participants will find the demo engaging and focused. Demonstrations deliver fast feedback, but only if they happen and only if they are engineered to facilitate a bi-directional exchange of information.

The basic mechanism of a demo is simple. Show stakeholders the completed work, let them interact with it and actively solicit feedback. I once heard someone describe this as running toward criticism. Where variations do happen they tend to be driven by scope, which implies different audiences, or by the geography of the team and stakeholders.  The variations in demonstration techniques are less about the goal of gathering feedback than about audiences and enabling the audience to provide the feedback.

Demonstrations occur on the last day of every sprint. They show the stakeholders what has been accomplished during the current sprint. The goal is for the team to gather feedback from the stakeholders so that they build what is needed and what the team committed to at the beginning of the iteration. The transparency created when the team shares its performance allows the team to rush toward feedback, while selling progress. Good demos include stakeholders interacting with the software so that everyone understands exactly what has been developed.

Demonstrations are the team’s mechanism to gather feedback and to ensure they are delivering value. I believe that demos have two currencies. The first is working software and the second is feedback. Teams build cache when they say what they are going to do, do what they say and listen to how their stakeholders feel about what they deliver.

Different songs have a different cadence.

Different songs have a different cadence.

If you listen to the radio, talk or music, you will notice that the cadence you hear varies song-to-song, show-to-show or podcast-to-podcast. One cadence simply does not fit all people or situations. Songs, talk or software development the concept is the same.  In Agile, there are three types of cadence variation. They are innovation or recovery sprints, slow then fast and irregular sprints. Organizations tend to push towards a standardized cadence however they a few twists and turns might add a lot of value.

Innovation or Recovery Sprints. Innovation or recovery sprints are sometimes used to demarcate periods of significant development effort. These types of sprints are generally part of larger cadence cycles, just like the changes of seasons mark the boundaries of solar cycles within the overall annual cycle. Activities in these types of sprints often include training, vacations, planning for future sprints or roadmap building. Knowledge generation activities in these sprints often include infrastructure building, prototyping, spikes, building out the architectural runway for the project and hackathons. Sometimes these innovation and recovery sprints are used for catchup or overall integration testing (if not possible during standard sprints). A Scaled Agile Framework Enterprise (SAFe) program increment is generally 8 – 12 weeks long made up of 4 to 6 2-week sprints. The last sprint is an Innovation Planning (IP) Sprint. All of the teams involved in the program increment participate in the IP sprint. In February 2014, Mike Cohn described an overall cadence of 6 x 2 +1, 6 2-week development sprints followed by a 1-week sprint for catchup, recovery and improving the team’s capabilities. The primary goal of innovation or recovery sprints is to improvement the capability of the team (or teams) involved. Learning, planning, exploration, reduction of technical debt and recovery improves the ability to deliver value when the next overall cycle begins.

Slow Then Fast Sprints. This variation is similar to the ebb and flow of cadence in a concert. The overall cadence at the beginning of many concerts I have attended are  generally slower than the cadence at the end. The cadence builds up to generate excitement so that then end of the concert is a crescendo. Recently at a monthly meeting of the Cleveland Agile Group, Chris Bohatka described a project that began with 2-week sprints, however 2 months before the end of the project shifted to 1-week sprints. The shift in cadence used the knowledge and team esprit de corps that had been built to accelerate the cadence and provide new functionality on a weekly basis. Interestingly it was noted in the presentation that the team probably would never go back to the longer/slower cadence. This is one of the VERY few times I have ever seen this behavior. Typically managers indicate that their teams will start with three or four week sprints and then accelerate, then the teams never accelerate their cadences. In theory this behavior seem to make sense however follow through is generally poor because team settle into a rhythm and get comfortable.

Irregular Sprints. While I have heard of Agile teams with irregular cadences, I have never actually seen a team perform in this manner over any significant period of time. Teams that are alleged to have irregular cadences often modify their cadence based on the story size and their inability to break them down. Sometimes implementation of continuous delivery, Kanban or a kanbanny-form Scrumban are confused with irregular cadence. These techniques, heavily influenced by lean, either don’t leverage or deemphasize the idea of cadence. They focus more on the continuous flow of work than on the time box that cadence generates. This is not the same thing as irregular cadence. Irregular cadence is most often a reflection of lack of discipline or a problem with how stories are being groomed.

A sustainable pace is one of the benefits of Agile. Sustainable is sometimes thought of as delivering prioritized user stories every “x” weeks, month in and month out. Innovation and recovery sprints interspersed at regular intervals are a great idea to ensure sustainability. Teams need to learn, innovate and in some cases catch-up to their promises. Interspersing innovation or recovery sprint at regular intervals is reflection of a higher order cadence. Using the knowledge gathered by working as a team, delivering functionality and innovation team can accelerate the cadence, or at least has the option so that functionality can be delivered sooner AND feedback cna be gained sooner. Irregular sprints rarely make sense unless teams are ready to move to continuous delivery. Cadence in Agile projects promotes predictability and discipline which are attributes valued by both IT management and the business.

Longer isn't necessarily better.

Longer isn’t necessarily better.

In Agile, cadence is the number days or weeks in a sprint or release. Stated another way, it is the length of the team’s development cycle. The cadence that a project or organization selects is based on a number of factors that include: criticality, risk and the type of project. As a general rule, once a team or a team of teams has settled on a specific cadence they tend not to vary significantly. While In today’s business environment a plurality of teams and organizations use a two-week sprint cadence, there is often a lot of angst over the finding the exact number of weeks in a sprint any specific team.  Many organizations adopt a standard and take the discussion off the table. With any specified cadence duration, there are typically three complaints: too much overhead, not getting stories done and not being able to commit resources on full-time basis to the work. In almost every case the complaint is coupled with a request to lengthen the duration of the sprint and therefore to slow the cadence.

  1. The sprint structure requires too much overhead: Sprints begin with a planning event and typically complete with both a demonstration and retrospective. Short stand-up meetings occur daily. Some team participants view these events as overhead. Scrum practice and observation of teams strongly suggests that the effort for the Scrum events increase or decrease depending on the length of the sprint. Longer sprints tend to require more planning and lengthier demos and retrospectives.  As a rule I suggest two hours of planning per week and 30 minutes each for the demonstration and retrospective per week in a sprint. Stand-ups should be approximately 15 minutes per day. For example, I would expect to spend 3 hours 45 minutes (2 hours for planning, 30 minutes for demo, 30 minutes for the retrospective and 45 minutes for 3 stand-up meetings) on events in a one-week sprint and 8 hours (4 hours for planning, 1 hour for the demo, 1 hour for the retrospective and 2 hours for 8 stand-up meetings). I have noticed that the effort for sprint events that are more than three weeks long tend to take longer than one would expect (four weeks sometimes being more than twice what is expected). Realistically, sprint size should not significantly affect overhead until you get to sprints duration’s of four weeks or more therefore overhead is not an obstacle to shorter sprints. Remember that in earlier posts we have shown that shorter sprints deliver feedback and value sooner so therefore are preferred all things being equal.
  2. Our stories can’t be completed during the sprint. This is typically not a problem with the duration of sprint, but either an issue of how the stories are split or a process problem. One typical corollary to this complaint is that the team can’t break stories into thin enough slices to complete. Most of the time this is a training or coaching problem rather than a technical problem, however in highly regulated environments or systems that affect human life I have seen scenarios where stories tend to require longer sprints due to very specific variation and validation. One common cause of this problem is assigning and hard wiring roles (testers can only test for example), which can cause bottlenecks and constraints if there is any imbalance in capacity. This is illustrated by the Theory of Constraints (take a look at our Re-read Saturday entries about The Goal for more on the Theory of Constraints). Typically, longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance because more stories are started and are subject to bottlenecks and constraints.
  3. Our organization can’t commit full-time resources to a sprint. Part-time team members typically have to time slice, switching between projects and pieces of work leading to some loss of efficiency. This is a reflection too much work and not enough capacity causing delays, constraints and bottlenecks. Similar to issue 2 above, typically longer sprints will not solve the problem. Unless the underlying capacity issue is addressed longer sprints typically equate to worse performance for the same reasons as noted above.

Many problems with cadence are either a reflection of process problems that generate overhead or poorly split user stories. For example, teams that do not have a groomed backlog will need to spend more time planning. Some team members see planning as avoidable overhead (the just wing it mentality). Overly large teams tend to have long daily stand-up meetings, again typically seen as overhead. Stories that are not thinly sliced will take longer to complete and have higher propensity to get stuck giving the team a feeling that a longer sprint is better. In almost every case, thinly sliced stories and committing to less work tends to improve the flow of work so that the team can actually deliver more. The duration of the sprint and cadence are usually not the root cause of the team’s problems.

#6 Make sure the telecommunications tools work.

#6 Make sure the telecommunications tools work.

In Distributed Agile: Distributed Team Degree of Difficulty Matrix, I described the many flavors of distributed Agile teams and the complexity different configurations create. While all things being equal, distributed team are less effective than collocated teams. Never the less, distributed Agile with teams spread across countries, continents and companies have become a fact of life. There are techniques to help distributed Agile teams become more effective. In an environment using Scrum, the first formal activities for most team’s is sprint planning. There are numerous techniques that can help make distributed Agile more effective. These techniques include:

1.   Bring the team physically together. Co-location, whether for a single sprint or some periodic basis, will increase the team’s ability to understand each other and know how to work together more effectively.
2.   Develop a sprint planning checklist. The process of getting together and planning is a fairly predictable process. Capture the typical preparation and meeting tasks and make sure they happen. Items can include booking rooms, securing video or telecom facilities, publishing an agenda with breaks and more.
3.   Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to plan. The definition of done will help the team know the tasks they need to complete during the sprint to meet the organization’s (or product owner’s) process standards.
4.   Focus on the stories. Don’t let distractions get in the way of planning. Before beginning the planning session, review the process that will be followed with the entire team. Make sure that planning the next sprint is the only topic on the agenda.
5.   Ensure that the stories have been properly groomed. The stories that the team will accept and plan need to be properly formed and have acceptance criteria. This generally means that the stories that are most apt to be accepted by team (and a few more) need to have been through a grooming session. Make this a prerequisite for the planning meeting.
6.   Make sure the telecommunications tools work and have a backup. Distributed planning means that all of the team will be using the phone or video conference. Make sure they are set up and tested. Also always have a backup plan in case your favorite collaboration tool fails because sooner or later it will. Planning is a whole team activity and when the whole team can’t participate planning, it will lose effectiveness.
7.   Everyone should understand the big picture. Have the product owner provide an overview of the goals of the project, and how the current sprint will support those goals. Repeating the big picture will provide the team with a common touch point to validate progress.
8.   Use physical tools for interaction. Physical tools, like flip charts and card walls, can be difficult when many locations are involved in sprint planning. However, when possible, use physical tools like flip charts and whiteboard and then use webcams (preferable) and cameras to share data. Have one location scribe one story and then switch locations for the next story.
9.   Try multiple facilitators. When a team is evenly distributed between two locations consider having another scrum master act as a second facilitator to ensure everyone stays on track. Similarly, have the Scrum master rotate between locations to facilitate the planning session. This can be very effective in helping each location feel connected.
10.Remember that sprint planning is a team meeting. Make sure everyone is involved.

Sprint planning, done well, helps a team understand what they have to do in order to consider a story complete, both from a functional and technical perspective. Distributed Agile teams will need to focus on making sure that everyone is involved and a part of the planning process. Remember to plan for planning, because when you are on the other end of a phone or videoconferencing the tools, process and logistics can make or break the meeting!

Use tools to keep the whole team engaged.

Use tools to keep the whole team engaged.

Distributed Agile planning is not any different from non-distributed in terms of its goal and process.  What should be different are the techniques and amount of facilitation.  Before we go further, I do not think there is any reason planning can’t be done amongst a distributed team. I do not believe there is any need to change the time parameters.  However, both of these statements are true only if the team stays engaged and the Scrum Master provides active facilitation.  The single biggest hurdle when a distributed team is involved in planning is keeping everyone engaged.

Visualization is a powerful tool to help foster engagement.  There are two types of visualization that are important.  The first and simplest is that all team members should be able to clearly see what is being discussed.  For example, I recently participated in an internal sprint planning meeting.  We used a screen sharing software that everyone on the team used.  As a story was discussed and planned, we brought it up on the screen so that everyone in the session could refer to the same set of words. Tasks, as they were identified, were typed directly into a shared document on the screen.  A second form of visualization relates to the team.  Use video on top of any screen sharing tools.  Seeing people as they discuss a point or talk about a story imparts significantly more information that just hearing them.  Think of how different the typical experience is when listening to radio compared to television.

IT personnel tend to be gadget and tool aficionados.  While a good tool for seeing the backlog or Kanban board is critical (emphasis on good, there are some re-purposed waterfall tools I would avoid like the plague . . . actually I might consider the plague first), the process needs to be simple enough that the set up time does not eclipse the planning time.  Tools like mind mapping software can be very useful to quickly capture and organize information. I personally use several including FreeMind (free and open source).  Another simple tool is Mountain Goat Software’s planning poker site at  I strongly suggest Scrum Masters (or coaches) walk through the tool suite they will use during planning before “going” live.  A simple check list of tools I use is:

  1. Screen Sharing Software: Tool examples include Webex or the like
  2. Video: Software examples include Skype Pro and OOvOO.
  3. Backlog/Kanban Boards: Examples include LeanKit, Kanbannery and Trello.
  4. Mind Mapping Tools: Examples include iTHoughts, FreeMind and Astah.
  5. Planning Poker Tool:
  6. Egg timer (or sometimes the timer on my phone)

The last item is capitalized because all bets are off if team members can’t hear each other.

Once the team has gotten over the hurdle of using the communication tools, the final problem is one of facilitation.  The Scrum Master needs to facilitate the process with special emphasis on making sure everyone participates and stays engaged.  They also need to pay attention to pace.  I use an egg timer to remind everyone of both the overall time box and the time box needed for planning each unit of work.

In distributed Agile, the planning process does not change.  However, keeping everyone engaged might be more difficult. The Scrum Master can make engagement more likely by making the process as easy as possible and making the process as personal as possible.  Planning is still a whole team sport, make sure that the whole team participates, no matter where they are.

0515131837Sprint planning is an important step in the process of delivering work in efficient and effective manner.  Unfortunately sprint planning is not always done well. When it is not done well it can yield less than wonderful results.  Four common problems are:

  1. Planning sessions are tedious.  Planning sessions where the team is struggling to understand the unit of work either due to lack of knowledge (including lack of acceptance criteria) tend to take forever . . . and ever . . . and ever.  Trying to develop the perfect plan and estimate will generally cause the same time dilation effect. Effective and efficient planning sessions are the outcome of units of work being groomed and prioritized and being understood or quickly explainable by the team. It is also important that the process is paced correctly and time boxed, which is the responsibility of the Scrum Master.  The session can always end early if you are done.
  2. Only part of the team participates in planning. As mentioned before, sprint planning is a team event – a whole team event. Letting individuals plan their own activities, breaking into subgroups and then planning, letting remote team members not participate or any combination of the later is a problem. Any of those scenarios will have negative consequences for the team, ranging from knowledge hoarding and holding onto specialties, to lack of esprit de corps. This “this is mine and that is yours” mindset for units of work will end in planning gaps.  Scrum Masters or coaches need to exert all of their influence to ensure the team plans as a team, and in a broader sense, that the team gels so that it does not act like a group of individuals.
  3. Planning sessions lose focus. I recently observed a sprint planning session that veered off track as team members began debating the merits of using as platform versus another cloud provider. It was fun, BUT not relevant. Teams lose focus because of a lack of preparation.  A backlog that is not prioritized or groomed or a sprint without a goal can let the attention of the team wander.
  4. Roosters in the hen house! Roosters are outsiders that participate in sprint planning and provide unwanted, unneeded and distracting advice to the team.  Sprint planning is a team activity. Planning should represent the needs of the product owner and the skills and capabilities of the team.  Teams that are brow beaten by outsiders into taking more work than they can accomplish or into doing work that does not represent the needs of the product owner will lead to ineffective planning session due to lack of team knowledge or worse, a lack of motivation.

When team members begin to look forward to sprint planning with as much anticipation as a root canal, something has gone wrong.  One of the most serious and easily fixed problems is lack of preparation. Lack of preparation has many consequences, none of which are good.  The hardest issue to deal with is the presence of ‘roosters’ in sprint planning, usually because the ‘rooster’ often has enough positional power to make it difficult to run them off.  The Scrum Master needs to shoulder the responsibility for helping the team to recognize and rectify all of these potential problems.  Scrum Masters and coaches of the world facilitate the process, make sure the team you belong to is prepared, stays focused and if absolutely necessary, meets in an undisclosed location.

Having common goals and definitions helps to lift the fog.

Having common goals and definitions helps to lift the fog.

The first two articles on sprint planning have sparked a number of interesting side conversations about logistics and precursor concepts.  There are several constraints, concepts and ideas that the team needs to keep in mind to facilitate effective sprint planning. For good planning, all teams must understand the goal of the sprint they are planning, the definition of done and the time box for completing planning. 

The sprint goal (or goals) is the high-level business and technical target for the sprint.  The goal acts as an anchor that roots the units of work that product owner will ask the team to complete in the upcoming sprint.  The sprint goal is a touch point that each team member can use to make the moment-to-moment decisions every development team makes. The goal can also be used as a communication vehicle to help stakeholders and others outside the team understand what will be delivered during the sprint.

The second concept all teams must understand prior to beginning sprint planning is the definition of done. The definition of done represents both the team’s and organization’s expectations of the state of the functional software when the sprint is complete. For example my standard definition of done is:

  • Design documents developed (if needed)
  • Code written
  • Required code comments written
  • Unit tests preformed
  • Integration test executed
  • Release notes developed
  • Acceptance criteria met

The unit of work is not done until all of these criteria are complete.  Every organization will have its own list of macro tasks that are required to show demonstrable value.  For instance, my base list includes design documents. Several of my clients are contractually required to produce design documents.  Without the design (or with an incorrect design document), they will not be able to deliver the software and get paid.

Third, the whole team needs to understand the planning time box.  As a general rule, the preplanning meeting should last no more than an hour for a two week iteration (30 minutes for a one week iteration).  The main planning session should be planned to last no more than two hours for each week of sprint duration.  The time box helps teams stay focused (also keeps me from telling stories), and from being overly precise (which usually represents false precision), which can cause the team to spin into planning paralysis. When the clock strikes the planning time box is over and the team needs to start executing.  The plan will be revisited during the daily meeting.

Teams need to begin planning with a firm grasp of sprint goal to provide direction and focus.  Explicitly understanding the expectations for what done means will help the team plan activities and tasks.  The definition of done also helps the team keep each other on track because they all have common expectations.  Finally, planning like most team sports, is constrained by a clock.  The time box keeps the team from spending the entire sprint planning rather than delivering.

Sprint planning is a team sport.

Sprint planning is a team sport.

Sprint planning is a collaborative process. It is an Agile team sport.  All members of the core team actively participate in the process with the focal point shifting as the process evolves. Mike Cohn describes planning in Agile like an onion – it has many layers. In the overall flow of an Agile project, the sprint planning comes after release planning and is the first step of a sprint. It precedes the daily meeting, which represents a lower level of planning. The basic flow I use for sprint planning is as follows:

  1. The product owner identifies the units of work he or she would like addressed in the sprint that is just initiating.  The product owner uses the prioritized backlog, the team’s velocity, information gathered through consultation with the team and interaction with other stakeholders.  In most mature Agile teams the process of prioritization and grooming of the backlog (which is central to the planning process) goes on constantly.
  2. Based on the list of work units that the product owner identifies, the team develops or reviews the size of each unit.  I am a proponent of story points or quick and early function points for the sizing process. Both processes help teams drive out ideas and assumptions about the unit of work that may not occur until much later in sprint.
  3. The team should make sure the sum of the size of the units of work makes sense based on the team’s velocity.  Said another way, make sure you are not considering more work than is rational to deliver.  The more comfortable a team (product owner, Scrum Master and the development team) becomes with their capacity, the less this step is needed.
  4. After the reality check, the team then breaks down the units of work into tasks and activities, including rough effort estimates. All of the tasks needed to meet the unit work’s acceptance criteria and to address all of the components of the team’s definition of done should be identified in this process.  The estimation process forces team members to consider how much work is required to complete a task.
  5. The sum of the required effort is used as a feedback tool for the team to gauge whether they can commit to the identified units of work.
  6. Have the team review the capacity of each team member.  This is important if team members are committed on more than one project (bad) or if you allow people to go on vacations (good).
  7. Once the team reaches a consensus on whether the work can be done in the time allotted, the team then publicly commits to doing the work.
  8. Draw a burn-down or burn-up chart for the sprint (both are described in Metrics Minute entries) for tracking, and finally get to work!

Sprint planning is a critical process for the team to develop a common understanding of what will be done during the sprint.  Sprint planning is one layer of planning in the overall continuous, collaborative planning process required for an Agile project.

Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.