Scrum “Inputs”

The Product Backlog is often described as the primary input to Scrum.  The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog.  In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog.  And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role.  I believe in just starting if you can.  I even wrote a blog post about this a while back and I stand by it.

I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing.  Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start.  And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.

The Scrum Guide recognizes the following inputs to Sprint Planning:

  • Product Backlog
  • Latest product increment (not applicable to first Sprint)
  • Projected capacity of the Development Team during the Sprint
  • Past performance of the Development Team (not applicable to first Sprint)
  • Definition of “Done” (implicitly)

A newly-formed team often needs to address the following before the first Sprint:

  • Product Backlog
  • Projected capacity of the Development Team during the Sprint
  • Definition of “Done”

If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).

Product Backlog

Keep it simple.  It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product.  Get the Product Owner to blow these things out into a list.  It doesn’t need to be a complete list.  Just the most important things right now.  A good test is to give the Product Owner 5 minutes.  Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on.  There are all kinds of techniques that can be used to order the Product Backlog.  The simplest way is to just have the Product Owner eyeball it.  If people are uncomfortable with this, then introduce the other ways.  It doesn’t need to be perfect.  It will get better and become refined and adapted as you go.

Projected capacity of the Development Team during the Sprint

Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%).  If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post.  According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).

Definition of “Done”

This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done.  The team needs to know this before it can estimate the items in the Product Backlog as a team.  Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.

Planning with the Product Backlog, projected capacity and Definition of “Done”

In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”.  Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done.  All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built.  The team should try to create a set of tasks each of which are a one-person day effort or less.  Count the number of tasks.  If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog.  If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of a Scrum Diagram

Over the many years that I have been teaching Scrum (since 2005!), I have had a diagram of Scrum as part of my slides and/or handouts.  The diagram has gone through several major and minor changes throughout that time.  Here is the progression from oldest to newest:

First Attempt

This diagram was used in some of my earliest slides when I first started delivering Scrum training.  It is bad.  It is woefully incomplete.  But, here it is:

01 Scrum Process Diagram

Second Diagram

I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.

02 All of Scrum Diagram

Third Try

The changes I made were small, but to me, significant.  Changing from a “mathematical” language of “Sprint N”, “Sprint N+1″ to a more general language of “Current”, “Future” was a big deal.  I really struggled with that.  Probably because I was still relatively new to being non-technical.

03 All of Scrum Diagram

Diagram Four

This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”.  It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram.  I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.

04 All of Scrum Diagram

Fifth Go

A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes.  I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram.  I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing.  Finally, I realized that I was missing an opportunity to use colour more systematically.  So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.

05 All of Scrum Diagram

Branded Diagram (ug.)

In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.

05 All of Scrum Diagram - Branded

Newest Diagram

Literally just a week ago, I was showing my brand-new branded diagram to a bunch of people who really care about design and UX.  The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!”  Well, that got me thinking deeply about the diagram (again).  So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!

06 The Scrum Process

The Future

I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game: Adaptive Planning for Adjusted Team Capacity in Scrum

Author’s caveat:

Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach.  Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony.  This is my other trick.

 Requirements for team estimation (and planning):

  • Product Owner
  • The whole Development Team (i.e. everyone who will be involved in doing the work)
  • Product Backlog
  • Definition of “Done”

 When team membership changes:

A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.

When team member allocation is adjusted:

Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.

Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.

WARNING:

The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.

Step 1 – What is our current velocity?

After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!

Step 2 – What is our current capacity?

As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:

50%        Chris P. Codemuncher

50%        Larry Legassifulunch

25%        Beth Breaksidal

40%        Gertrude Gamesthadox

40%        Dana Deadlinedryver

The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 25% = 2.13 days    Beth Breaksidal

8.5 x 40% = 3.4 days      Gertrude Gamesthadox

8.5 x 40% = 3.4 days      Dana Deadlinedryver

17.43                              Total combined available days per Sprint

Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.

Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:

21            Velocity

17            Capacity

21/17       V/C

(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)

 Step 3 – How much capacity do we hope to have in the next Sprint?

Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”

Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…

But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:

8.5 x 50% = 4.25 days    Chris P. Codemuncher

8.5 x 50% = 4.25 days    Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 15% = 1.28 days     Dana Deadlinedryver

16.58                               Total combined ACTUAL available days in Sprint 1

16                                    Actual capacity (rounded-down)

21/16                               Actual V/C

As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.

Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:

8.5 x 100% = 8.5 days     Sally Supaspeshalis

8.5 x 100% = 8.5 days     Chris P. Codemuncher

8.5 x 75% = 6.38 days     Larry Legassifulunch

8.5 x 50% = 4.25 days     Beth Breaksidal

8.5 x 30% = 2.55 days     Gertrude Gamesthadox

8.5 x 0% = 0 days            Dana Deadlinedryver

(Note: Dana is also the Scrum Master with plenty of other work to do for the team)

30.18                               Total combined hoped-for available days in Sprint 1

30                                     Hoped-for capacity (rounded-down)

Step 4 – How much velocity do we hope to have in the next Sprint?

21            Actual Historical Velocity

16            Actual Historical Capacity

30            Hoped-For Future Capacity

x              Hoped-For Future Velocity

Some simple math, loaded with assumptions:

Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity

Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375

39            Hoped-For Future Velocity

Step 5 – How do we adapt our planning in light of what we now know (assuming we now know something substantial enough to inform our planning)?

Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.

Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!

See you next time,

Travis.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner never interrupts the team mid-Sprint with new “high-priority” Product Backlog Items

The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint. New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner always lets the team freely decide how many Product Backlog Items to do in a Sprint

The Product Owner controls the order of the items in the Product Backlog, but not how many are done each Sprint. Instead, the team decides how many to do. This decision is made in Sprint Planning and, of course, should be made in collaboration with the Product Owner, but ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done. If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner knows if the estimated financial return of the work of a Sprint is higher than its estimated cost

The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.

To learn more about Product Owners, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting

The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.

To learn more about Sprint Planning Meetings, visit the Scrum Team Assessment.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Your Product Owner uses the Sprint Review to help the team continuously improve the product

The Sprint Review is a key meeting for the team to improve the product. There are three main purposes of the Sprint Review: inspect how the last Sprint went with regards to the product; identify the items that are complete and order any potential changes; and, integrate those changes into the Product Backlog. This meeting aids the team in inspecting and adapting the entire product increment and how the team is progressing towards any deadlines. The Sprint Review is a check point that helps the Scrum Team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the Scrum Team to look at the product clearly (it’s not just for the stakeholders!). When a Scrum Team refrains from having and participating in this essential meeting, the is team is likely to become a Scrum Team in name only without any of the far reaching benefits that many other Scrum Teams have experienced. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.

What is the main purpose of the Sprint Review? Bottom line: to get feedback on how well the work the team is doing will satisfy business needs.  If the team isn’t getting that feedback in a practical concrete form, then the Sprint Review needs to be improved.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I work with all the team members to expand the Definition of “Done”

The Definition of “Done” for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint.  Expanding the Definition of “Done” until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance.  Team Members expand the Definition of “Done” by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities.  When every Team Member is systematically expanding the Definition of “Done”, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources.  If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: The top PBIs are small enough (effort) that several can fit into a single Sprint

Product Backlog Items (PBIs) that are at the top of the Product Backlog (in other words, those which are to be done next), need to be small enough that the Scrum Team can comfortably complete all the work for them within a single Sprint.  The Product Owner should be spending a little time every Sprint to split “large” PBIs into small PBIs.  The Product Owner relies on the team to estimate if they are small enough.  If the PBIs are not small enough then large problems can arise.  Probably the most serious problem is that the Scrum Team may be unable to start and finish PBIs in a single Sprint which can seriously hinder the “inspect and adapt” process due to Sprint results that cannot be demonstrated in the Sprint Review.  Almost as bad, incomplete work can leave a mess in the system if the Product Owner for some reason decides to change priorities and not complete work started in a previous Sprint.  Finally, incomplete work dis-empowers the Product Owner from being able to make a business-based decision to ship or deploy the Team’s work at the end of the Sprint.  A smaller problem that can arise from PBIs that are large is that the Team may not be able to fill their Sprint as effectively.  One way to think about this is the difference in how much empty space there is in a cup filled with large pebbles versus a cup filled with sand.  The rule of thumb is that PBIs should be small enough that between five and ten fit into every Sprint.  This is often the right compromise between the effort required on the part of the Product Owner to write small PBIs and the risks mentioned above.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: The scope of work for a Sprint is never expanded mid-Sprint (interruptions)

The Scrum Team plans their work in the Sprint Planning meeting and that planned scope (Product Backlog Items) is meant to be respected… it is a commitment by the team.  In exchange for that commitment, the rest of the organization commits to leaving the team alone to focus on its work.  Focus and commitment are both important values of Scrum.  Any interruption to any individual Team Member except the ScrumMaster and Product Owner is considered a cause for relieving the Team of its commitment.  This rule of Scrum is designed to put pressure on the organization to leave the team to focus on the most valuable work.  If the organization allows interruptions to the team’s work during the Sprint, then the team will not meet its commitments and this will diminish trust between the team and its stakeholders.  That lack of trust will lead to onerous control mechanisms that reduce the team’s ability to self-organize which, in turn, will prevent the team from becoming a high-performance team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: There is no break between Sprint Review and Retrospective meetings

After a team finishes its Sprint Review, the Retrospective meeting should begin immediately.  Of course, there may be a small transition period as non-team members leave a meeting room or as the Team Members go back to their team room.  However, there should be no work on the system done between Sprint Review and Retrospective.  This quick transition between the two meetings is primarily to ensure that everyone has a clear memory of the Sprint.  If there is a gap between the two meetings it can lead to a number of sub-optimal behaviours: team members may do work without the knowledge of the rest of the team, there may be a growing desire to delay the retrospective, or even pressure to skip the retrospective.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Review and Retrospective meetings are timeboxed in total to 2 hours / week of Sprint length

Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants.  In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint.  For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total.  It is acceptable for the meetings to take less time, but not more.  A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours.  Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time.  If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Every Sprint includes Sprint Retrospective for the team to inspect and adapt

The last part of the Sprint is the Sprint Retrospective.  This meeting is a private meeting for the members of the Scrum Team (including the ScrumMaster and Product Owner).  In this meeting, the Team Members discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint.  Scrum does not define any particular techniques to use during the Retrospective meeting.  The Retrospective is complementary to the Sprint Review.  The Review inspects “what” was done and the Retrospective inspects “how” it was done.  The Sprint Retrospective is critical for the team to apply the principle of “inspect and adapt” that is core to Scrum.  Missing the Sprint Retrospective is a critical failure of the ScrumMaster’s job to ensure that the principles of Scrum are being used.  If a Retrospective is missed once, what may happen is that some Team Members might feel that missing it was not so bad.  There will not likely be any immediate consequences to missing the Retrospective.  However, the attitude that the Retrospective is not important will be implanted in the team.  This then quickly leads to further compromises and eventually, the continuous improvement parts of Scrum are abandoned and the team focuses purely on the execution parts of Scrum.  The team will then fail to become a high-performance team since that high-performance state is predicated on systematic, conscious self-improvement of how the team does its work.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: Every Sprint includes Sprint Review for stakeholder feedback on the product

Scrum is a tool for product development that uses transparency and fast feedback.  The Sprint Review is an open meeting during which the Scrum Team works with all interested stakeholders to look at the results of the Sprint.  This meeting is usually dominated by a demonstration of the working increment of software.  The stakeholders in attendance at this meeting freely provide feedback about the product which is then used by the Product Owner to update the Product Backlog.  This feedback is critical to ensure that the team is staying on-track, that it is building the most valuable possible product features, and that the stakeholders are satisfied with the results.  Missing this aspect of feedback makes Scrum only modestly better than non-agile approaches to doing work and should be considered a critical problem to fix as it undermines the whole point of doing Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail