Patterns of Agility, talk at Scan-Agile 2011 and Agile Riga Day 2011

Some time ago I wrote a post here about Patterns we can identify in projects and how they relate to the life-cycle model in use for the project.

Some patterns are definitely signs of an Agile project (release working software at the end of every *very* short iteration for example). Other patterns are clear signs that we are in the presence of a waterfall project (writing never ending power point presentations to prepare a project approval and then rushing with the actual coding).

There was quite a lot of good feedback on that post and @lebedev_dmitry even suggested that I present a talk at Agile Riga Day on the same subject.

So I prepared a presentation to explore this theme. You can check out the presentation in my slideshare page.

But I felt that a presentation was not enough. Yes, we need to introduce the idea of patterns and how to recognize the context in your project, but we also need to reflect on the actual patterns we see in our projects. So I decided to end the presentation with a short reflection/retrospective exercise: the Agility Score Sheet.

Try it out. Read the presentation, then take the sheet and score your project. What did you find? What thoughts came to your mind after completing the exercise? What will you change tomorrow?

Feel free to edit the Agile Score Sheet. I've opened it so that anyone with this link can read it and edit it directly.

PS:
If you attended Scan-Agile 2011, you can rate my talk here
If you attended Agile Riga Day 2011, you can rate my talk here.



Photo credit: Bill Gracey @ flickr

SWAT Team, a Pattern for Overloaded, Multi-project Organizations

We all have seen it in our projects. Some teams are overloaded and can't deliver what we need while others are not so busy and could even tackle more work if there was a need for that.

This type of partial overloading is easily understood if we picture the work flow as a network of nodes. The throughput of the overall organization is limited by the nodes that are overloaded, even if not all nodes are overloaded.

The situation is even worse in multi-project organizations where many projects compete for staff time which leads to optimize for staff-loading optimization and ultimately to overloading the organization by creating certain bottlenecks that block all work for one or multiple projects.

Why does this happen? and How to tackle it?

Below is a short pattern description of one of the possible ways in which we can tackle this type of situations.

Problem and Contribution

As explained above, the problem symptoms are typically that some teams are overloaded and cannot take on more work. This work is essential to meet a particular deadline or to get a project started.

Other symptoms may include:

• Line Managers requesting more resources on a regular basis.
  
• Long meetings with two or more people where the allocation of one person is discussed at great length.
  
• Projects are started officially but no progress is achieved due to ongoing projects having higher priority.
  

A typical result is that some project gets delayed or a project that is started gets starved for resources. The problem can generically be defined as a resource allocation problem. In computer science literature this is also sometimes called a Scheduling problem.

In this pattern we outline a simple strategy to tackle this project starvation in an overloaded multi-project organization.

Context

This pattern is applicable to any organization that has several teams and/or multiple projects (typically a non trivial number) and where the symptoms can be seen, but the root cause cannot easily be found or solved.

An example is a large software development organization where many teams contribute to multiple parallel projects. In these cases it is perhaps possible to find the root cause for the delays and starvation of competing projects, but it is either not practical (no people with enough knowledge of the overall organization or no people with experience in large complex network management) or not economically feasible (the time and money it would take to find out the root cause can better be used applying a simple pattern like this).

Forces

• In an organization Line Managers (people that coordinate and prioritize work at a sub-level, typically a team or subset of teams) are motivated to show that their teams are busy. Given this constrain it is typically very difficult to assess the actual load in all the teams in an organization. This is because even if one line manager would be honest and inform that their teams have some bandwidth, there would quickly be more work assigned to those teams so as to overload them.
  Alternatively, other managers would complain that their teams are overloaded and require that the available teams be assigned to them, therefore assigning the "busy" line manager more power in the organization, which in turn re-enforces the message that "it is not OK to say that your teams are not overloaded".
  
• Teams themselves have no incentive to publicly state that they are not overloaded because that leads to job insecurity or scorn from surrounding teams (see also above).
  
• In any mid- to large-size organization (more than a few teams) it is very difficult to unequivocally identify which are the teams that are overloaded and which may have some bandwidth. This is because changes to the software may cause a previously free team to become busy and assigning more work to that team may jeopardize the work needed when future changes are recognized.
  
• The larger the organization the more specialized the workers tend to be, which in practice makes it very difficult for teams to help each other by sharing a common work log (aka backlog) or for one team to help another that is working on a different component of sub-system.
  
• Many organizations start multiple parallel projects. This typically leads to overloading the organization even further and putting more pressure on certain teams that are in practice bottlenecks for the flow of work. Multiple projects dependent on one team become therefore "stuck" and their requests cannot be completed. This often leads to other teams being stuck as well because they depend on the bottleneck teams. Finally the organization may have multiple teams that cannot deliver their work because of one single bottleneck. This is a common feature of networked systems such as the Internet.
  

Solution

In this post I try to present a simple solution. The goal with this solution is not to optimize staff utilization, or to explore complex mathematical models. Rather this solution focuses on something that is easy to understand albeit more expensive than other possible competing solutions.

As explained above, mid- to large-size organizations tend to build complex networks of teams through which the work flows. These networks tend to be complex as well as unstable (i.e. the node links change frequently due to rerouting of different types of work).

A simple solution will have to work independently of the characteristics of that network, thereby being network agnostic.

Create a team of generalists and assign those to one of the ongoing projects and make it report to the project management team as opposed to the line managers. This way the project management team can assign this team of generalists to help some of the teams that may be blocked on some piece of work. Additionally this team will collect tacit knowledge about the prevailing bottleneck areas and will therefore also be useful in debugging and investigating specific problems in those areas later on.

This team must be staffed with people that can easily touch any component or subsystem and ideally these people will be very well networked in the organization in question, allowing them to quickly tap into more specialized knowledge when needed (say over the lunch break or on a quick IRC chat).

This team, which I'll call SWAT team (for SoftWare Action Team) will work under the guidance of one person with Project Management responsibilities and will answer only to the project management team, not the respective Line Managers. The reason for this is that the project management team is motivated to solve specific problems that allow the project to progress and have access to the information about which areas/teams/sub-systems need more work to make that happen.

Resulting context

When the SWAT team is nominated it must be staffed out of the best software specialists (Architects, testers, designers, coders) in the organization. This means that other projects will lose some man-power and potentially lose people that helped those projects progress faster. For this reason it is important to be flexible at first in the nomination of this team and consider every individual assignment together with both the software development teams and the project management teams.

A possible consequence of the nomination of this team is that the team is kept together for a very long time, therefore reducing the staffing levels indefinitely for other software development teams or projects. This is not a desirable situation. The SWAT team should be a temporary team, brought together only to help the previously-starved project progress. Once that project raises in the priority list or is not starved then we must consider stopping the SWAT team's work and returning them to their original teams.

Another risk that should be considered is the loss of specific knowledge on the part of the SWAT team. This is particularly problematic if some of the individuals work in highly specialized teams within a specific knowledge that evolves fast. Therefore the SWAT team should be as short lived as possible but put together whenever needed.

When selecting the individuals for the SWAT team one must also consider the motivation of those individuals to participate in a generalist team. Some will undoubtedly be happy to do so, but others may not.

Queuing Theory and Throughput

The basic systemic impact of the SWAT team is that it transfers people from the day-to-day work (which is typically optimized for staff utilization, i.e. getting everybody busy) to a sporadic or ad-hoc work which is assigned on a need basis. This effectively creates a staffing "buffer" by which we reduce the number of people that are constantly kept busy or in full-utilization. We then use this SWAT team to tackle particular bottlenecks.

Finally, the SWAT team has very little impact on the organization utilization (only a few individuals compared to many teams), but it creates a small surplus capacity that can be applied to any bottlenecks to solve the problem of a starving project.

A Question for you

Have you seen this pattern applied in your organization? What were the results? Share those with us in the comments below.

See Also

• Component teams
  
• Feature teams
  
• Maintenance teams
  
• Pattern "Someone always makes progress" published in [Coplien2005]
  
• Pattern "Team per Task" published in [Coplien2005]
  
• Pattern "Interrupts Unjam Blocking" published in [Coplien2005]
  
• Keeping everybody busy (anti-pattern)
  

Reference

• Organizational Patterns for Agile Software Development by Coplien and Harrison
  
• The Principles of Product Development Flow: Second Generation Lean Product Development by Reinertsen
  

Pattern format description

In "Name" I give a name to the pattern.
In "Problem" I describe the problem the team is facing in the form of a root cause and a set of symptoms that may be detected and lead to this problem.
In "Context" I explain where the pattern is applicable.
In "Forces" I try to describe the constraints or forces that the solution has to take into account.
In "Solution" I try to describe the instructions and practices to be used to solve the problem as described.
In "Example" I briefly explain the case of one team at work that has faced this problem and how they solved it.

Photo credit: Dunechaser @ flickr

Patterns of Agility. How to recognize an Agile project when you see one...

Instead of fighting about "who's agile" or "who's more agile than whom", it would be useful to create a set of patterns, that once recognized would help us define if we are or have been able to successfully implement an Agile life-cycle for our project and portfolio.

These patterns or symptoms are useful for us when analyzing a project (e.g. for a retrospective) and assessing the progress of a team or a company from waterfall to Agile software development. These are necessarily only a small collection of patterns. Many more are needed to create a complete language that would help us define better what an Agile project should feel and look like.

Before getting deeper into the patters let me define at the outset what I mean by life-cycle. In my context life-cycle refers to a stage/phase in the life of a project. Example: a project that is "about to end" is in a different life-cycle phase than a project that is "about to start" or "ramping up". I define the following useful, although not exhaustive, life-cycle phases: Start, Middle, End.

In the following text I try to define what different types of projects (Waterfall, Linear Iterative and Agile/Incremental Iterative look and feel like.

Waterfall

Life-cycle phase: Start

In this life-cycle phase a waterfall project is typically in a phase where only the project management team is assigned to the project and the goal is to create a plan. The plan is typically composed of a set of requirements, an architecture target (maybe an architecture plan or just a high-level picture to be developed further), a budget and (most importantly) a project plan.

You know you are in a waterfall project when in the life-cycle phase Start you are mostly spending time in front of a presentation or word editing software and have some meetings (maybe weekly) where scope, budget and project plan are discussed. This phase typically ends with a "gate" where the project plan and Requirements + Architecture are approved.
A dead give away of a waterfall project is that, in this phase no one asks or worries about writing a single line of code. Some sophisticated waterfall projects may include a "prototype" in the life-cycle phase Start, but it will usually be a throwaway and developed by a sub-contractor who will not actually work in the project (after all the other teams are busy with the other projects).

Life-cycle phase: Middle

In this phase the project is in "full speed", which usually means that teams are working with very little coordination (after all they have a "plan" to follow). Typically components are assigned to teams and they work on those in isolation.
A dead give away that you are in a waterfall project is that your team does not integrate code with the other teams at all. Some sophisticated waterfall projects may have "sync-points" or "integration camps" where the component teams come together after a long period of development to integrate their code. These are grim affairs with much overtime and gritting of teeth.

Life-cycle phase: End

In this phase the waterfall project is "code complete" and aiming to "code freeze". There is usually a milestone/gate that was passed exactly at the start of this life-cycle phase called "code complete" or "feature complete". It is at that point that the teams of testers (typically many and in some far away country) are assigned to "test" the product. Obviously what they will be doing is a rather superficial sweeping of the floors to check that everything works. It is only after that that the project can pass the "code freeze" milestone/gate and the real testing can start.
You know you are in a waterfall project when the project runs out of time before it has quality enough to be released. The number of bugs being found is still very high, but probably at about the same level of the bugs being fixed. This is when "management" comes in and pushes all the teams to fix as many bugs as they can (pulling all-nighters or all-week-enders if needed). Much motivational language is used but the count of bugs being fixed stays about the same. The project will eventually ship something, but the actual quality level can only be vaguely understood. Business takes precedence in the decision making.

Iterative, aka Linear Iterative

Life-cycle phase: Start

In an iterative project the Start phase will typically be called Inception and will, like the waterfall projects focus mostly on defining requirements and creating/approving the project plan.
You know you are in an iterative life-cycle project when people start actually coding, but only a few features. Programming is still being "ramped up", but there's no milestone/gate that formalizes "start-programming" order.
In some sophisticated Iterative projects people will mention Use Cases, customers, experience, business cases and may even have a prioritized list of Use Cases to be implemented. Typically you will find that the Requirements document is quite shallow, delegating the clarification of most requirements to the actual "design" phase of the project.

Life-cycle phase: Middle

Now the teams are working very clearly on the code. Some Iterative projects may even have several sync points (see above) within this life-cycle phase. They will be easier than in a waterfall project, but "integration camps" are still common (although less frequent) and teams actively discuss the "code-line" policy (i.e. version control is an active part of project management.
A dead give away of an iterative life-cycle is that there will be several iterations of about 2-3 months in length at which point many teams try to integrate their code. In some sophisticated Iterative projects the teams will actually try to hold demonstrations of the existing code and in some (far fetched) cases there will be a project-wide retrospective at this point.

Life-cycle phase: End

You'd be tempted to think that Iterative life-cycle projects would have an easier "End" phase, but you would be wrong. Just like in waterfall, the teams develop a lot of their code in their own version control systems and integrate seldom (although much more frequently than in a waterfall project). In large iterative projects there will be "vertical" sub-projects (typically less than 100 people) that will actually integrate their code frequently but the multiple concurrent sub-projects will only really integrate their code at the end.
In this type of projects you will still find a very hectic "test and fix" phase at the end, but it will typically be focused around "complex use cases" as many of the simple use cases have already been tested during the "Middle" life-cycle phase.
You know you are in an iterative project because just like in waterfall Quality is an after-thought and you will find many, many bugs in the end of the project. The defect/error metrics will be the main focus of the project management team in this phase, up to the point that sophisticated statistical models will be created to try to predict when the project will end.
Don't be fooled, in a project where error/defect metrics are used as the main project management tool no one is in control. The project end date is essentially unpredictable and typically management will decide (arbitrarily) when the product should be released.
In some sophisticated Iterative projects I've seen that a length is pre-set for this life-cycle phase based on history and, ironically, that seems to hold pretty well (although not for the reasons you may think! -- stuff for another post)

Agile, aka Incremental Iterative

Life-cycle phase: Start

In an agile project this phase is typically extremely short. A product manager will present a proposal for a new product or a new version of an existing product. This proposal will be discussed and approved. One or more teams are assigned to the project for a short period of time (called Sprint or Iteration -- confusing, I know) and produce a running product, called a Product Increment.
You know you are in an Agile project when the team talks about "releasing" the software starting from day one. Each development team will include testers and each Requirement (aka story or feature) will be discussed in order to create acceptance criteria (aka conditions of satisfaction, aka test cases). These will typically be agreed before the team sets out to design the implementation but can also be updated during the Sprint/Iteration.

Life-cycle phase: Middle

In this life-cycle phase you will notice that the teams start to gel (if they are new) and the project gains momentum. The teams demonstrate regularly what they have accomplished and some teams will have stopped holding retrospectives, because they "have nothing to improve". The pressure is always high in an Agile project, but never too high, and in this phase of the project the team is already used to the pressure level, they know how to tackle their stakeholders.
You know you are in an agile project when the Product Manager is not the Product Owner and is never or almost never present in the Sprint/Iteration planning meetings. That work is delegated to someone in the team that knows the technical product and works with guidance from the product management to help the team manage and prioritize their backlog (aka Technical Product Owner).

Life-cycle phase: End

This is the life-cycle in which the Agile project will differ the most from the other two life-cycle models. In the end of the project the team will still be developing new features at full speed. No one will talk about "code freeze" or "feature freeze" in the project, but the testers and project management team will closely follow the Defect list.
You know that you are in an Agile project when the defect/error list is short and the selection/prioritization of defects/errors is easy. Some teams will just start their iterations/sprints by picking the most important defects out of the defect backlog, others will reserve some time/bandwidth in iteration/sprint planning specifically to improve the quality of their product.
The most noticeable difference however, will be that people will feel the pressure to add more features at the end, rather than the pressure to avoid changing any code. Agile projects typically deliver a large amount of "test" code (i.e. code that is there to test the production code) which makes them confident that they can change the code up to the last minute of the project.

Conclusion

I hope that this collection of patterns from different types of projects will help you talk about the level of agility in your project with your team.
We should really stop bickering about "how agile we are" and start defining how an agile project "feels" like. What patterns do we see, what benefits and constraints we have, etc.

At the end of the day, what matters is that you understand your context. That's the first step to changing it!

Photo credit: Bill Gracey @ flickr

Story points explained, a good addition to the timeboxed estimation pattern

Just after writing the post about about Never ending design discussions I found one post from Lasse about story points. I think these two posts go very well together, as story point-based estimations is what I use for the Timeboxed estimation pattern.

End the never ending design discussions: Timeboxed estimation for User Stories, a pattern in Agile adoption

In this post, Jason explains one common problem with the estimation and planning sessions in Agile teams. The problem he describes however, is quite common and has lead to implementation of the Separate Design and Requirements anti-pattern in the traditional software development world.
So I thought I'd write a pattern about a simple and common solution that I've seen and applied to solve that problem.

Timeboxed User Story estimation

Problem:

In the first part of the planning meeting the Scrum team and the Product Owner will review the top User Stories in the backlog to make sure the team and the Product Owner share the same understanding of each User Story.
In the second part of the planning meeting the team will do a short design discussion for each of the items. The discussion should be around what needs to get done for each User Story in order to collect Meaningful Tasks and make the work clear to the whole team.
When the team gets to the definition of meaningful tasks they will get stuck in design discussions often spending too much time in the first one or two stories and then not having a complete decomposition of the other User Stories that would organize the sprint for the team.
Some consequences of this problem are:

• missed tasks in the sprint backlog that end up not being done;
• mis-understanding of the User Story design that leads to inconsistent design decisions;
• unclear definition of the design for a User Story that leads to inconsistent and sometime incompatible architectural patterns in components that need to interact (especially when in the presence of Component Teams);
• Cowboy Coding.
  

Context:

This pattern is applicable in the context of the planning meeting, but can be used also when reviewing a Product Backlog before the planning meeting (see Prepared Product Backlog).
The same pattern can be used to estimate any attribute of a task, such as effort, risk or business value.
In order for this pattern to be applied the team needs to agree to use the same technique. Sometimes some of the team members will refuse to use this practice by stating that it is not "serious" enough or challenging it's credibility. Alternatively people can say that with this method we cannot get "good" design, however it is important to point out that the aim of the planning meeting is not to set the "final" design, but rather the first iteration of the design and especially to achieve consensus with the team on the design patterns and architectural approaches selected. The design, as well as the product, should evolve during the sprint.
In my experience this technique can be successfully used in teams of up to 10 people during the planning meeting.

Solution

The solution is to time-box the estimation for every single User Story, not just for the meeting. Note that the team needs to agree how much time they will spend for each item they accepted for the sprint that is starting. We have used 5 minute time boxes for development stories and 2 minutes for management-related stories.
At the start of the meeting the team agrees on the size of the time box in such a way that it allows to cover all the stories needed within the length of the meeting. For example, if you have 10 stories to cover and 60 minutes meeting that means that after 5 minutes you need to move to the next story (that will give you a 10 minute buffer).
The process for each story is:

1. The facilitator reads the story from the product backlog
   
2. The teams ask questions or define tasks by talking about the design of the implementation
• Example questions are: what modules will this story touch?; do we need help from any other team?; do we already have module X in our version control?; do we have the design for the UI?; will we need to manually test this feature or is it enough to have the automated user acceptance tests?; etc.
  
3. While the team discusses the needed design changes/additions the facilitator writes down the clear tasks (example: refactor class X, change the algorithm for Y, design a view for Z, get support from the DB admin for the DB upgrade in the test environment, etc.)
• For some tasks to be clear, the facilitator may need to ask clarifying questions. See step 2 for examples.
  
4. At 4 minutes (if the timebox is 5 minutes), the facilitator will request everybody to estimate the story (using the Planning Poker method for example).
5. If there is no consensus on the estimation, the discussion continues
• At this time the facilitator can focus the discussion by asking the highest and lowest estimate person: "Why do you think that is the case?"
6. At 5 minutes the facilitator will ask everybody to estimate the story and note down the most popular estimate value
7. The facilitator closes the estimation for this story. Return to step 1.

After the meeting the team has a preliminary list of tasks (that will be improved during the sprint) and a consensus on some basic, yet critical design/architectural decisions.
Even if this method seems "minimalist", our experience is that it works well-enough even for 4 week sprints. Although, due to the size of the tasks it is easier to apply to 2 week sprints.

Resulting context

• The first few times the team will try this technique their discussion may be very superficial, especially if the team has never had design discussions in short spurts before. This is to be expected and the experienced ScrumMaster will keep her ears open for symptoms of this during the daily meetings and call for additional design discussions during the sprint, when needed.
  
• The first few times the team may feel that the process is "artificially" strict. This is a common critique. However the team should stick to the practice for at least 4 sprints before changing it or "customizing" it. Our experience is that people will adapt to the method and, after some sprints, start producing high-quality high-level design already during the short discussions in the planning meeting.
  
• If the first part of the planning meeting was not enough to clarify the aim of each of the stories to be estimated the team may have to discuss the stories from the requirements perspective before they can have a design conversation. In this case the facilitator should stop the discussion and defer the estimation of that task to when the Product Owner has explained well enough the story (this is the Unclear Stories anti-pattern).
  

See Also (patterns and anti-patterns not defined yet):

• User Stories for communication across functions
  
• Meaningful tasks
  
• Component teams (anti-pattern)
• Cowboy coding (anti-pattern)
• Unclear stories (anti-pattern)
• Prepared product backlog
  

Resources

A good practice for the actual estimation is the "planning poker game". Here are some resources:

• A timer for planning poker
• Planning poker explained
• A web-based planning poker for distributed teams
  

The Proxy Product Owner, a pattern in Scrum adoption: version 1

Below I try to describe a pattern that I've faced and have seen in other teams in the context of an Agile transition.
See the explanation section for more details on each of the sections in the pattern.
If you have faced similar situations let us know of your own story in the comments below.

Proxy Product Owner

Problem:

There are 2 or more Product Owners that give work to the Scrum team and the Scrum team has several systems to maintain. Each Product Owner owns only a subset of the systems the team works on and is only interested in the systems she owns.
The team is faced with unclear priorities, Product Owners who do not want to agree on the priority of each other items, and because each Product Owner has their own Product Backlog, the team has a hard time coordinating the work that they need to manage sometimes leading to the team creating their own Backlog that is hidden from the Product Owners, and where the real priorities are set without their knowledge (this is the Secret Team Backlog anti-pattern).

Context:

This pattern is applicable when the Product Owner community for one development team can not reach agreement without the intervention of a third person that will help them define the right priority for all the backlog items.
This pattern applies equally well if there is a decision within the organization that some products, and therefore the respective Product Owners, should receive a higher level of service.

Forces:

• Typically the team is paralized or hampered in their effort by the lack of clear priorities.
  
• In some cases the team ends up delivering features that are not in line with the company or customer needs
  
• The ScrumMaster will spend most of her day managing the Product Backlog and answering uncoordinated requests from all stakeholders
  
• Stakeholders include the Product Owners, but in some cases the Product Owners don't act as a proxy, but rather delegate their responsibility in the users/customers they represent. In this case the team and the ScrumMaster are faced with many conflicting signals about what the real priorities are.
  

Solution

The ScrumMaster takes charge of the Product Backlog, which in this case will become a Team Backlog, in that it includes items for all of the systems that the team manages, not just one product.
The first goal for the ScrumMaster is to get the Team Backlog in shape so that the team can start working from the Team Backlog without having to spend many hours getting the Backlog In Shape.
Once the team can consistently take items from the backlog without a need for large interactions with the Product Owners, then the ScrumMaster can start using the techniques described below for the proper prioritization of the Backlog by all stakeholders.
When several (2 or more) Product Owners are involved in the prioritization of the backlog it is important that all of them understand the need to serve all Product Owners and not just one, therefore the prioritization technique should reflect that fact.

Equal weight for all Product Owners

In this case all Product Owners have equal importance for the organization and therefore they should be assigned the same amount of decision power. That is done by giving each Product Owner 1000 points that they can distribute among all items in the Product Backlog. Each product owner knows that all others have the same amount of points to distribute, therefore they will be forced to "invest" more points into the stories/use cases/backlog items that they really want to get done in the next few iterations.
Each Product Owner may also invest points into other systems than their own, if that will help them get some feature in their own systems.

Different weight for each Product Owner

In this case one Product Owner is considered more important. He is given a larger percentage of the points available. The points given to each Product Owner should be similar to the company investment level decisions. For example, if a Product Owner's product is to receive 70% of the investment, the she should be assigned 70% of the points available for distribution among product backlog items.

Resulting context

• Once the ScrumMaster takes ownership of the Product Backlog the Product Owners will now focus on influencing her and get her to make decisions that are favorable to their needs. This should be avoided and the ScrumMaster should follow as much as possible the real results from the the prioritization done through the distribution of the points by the Product Owners
  
• In some situations some Product Owner will not do the prioritization before the Planning Meeting. In this case the ScrumMaster has a choice of letting the Product Owner assign a subset of her points during the meeting -- as not to delay the meeting too much; or then not allowing late prioritization, in which case the team will not work on the systems owned by that Product Owner.
  
• For this pattern to be implemented the ScrumMaster will have to spend a large part of each day managing the Team Backlog and communicating with the Product Owners. The team and ScrumMaster should be aware of this and decide to invest the ScrumMaster's time in that task.
  

Example

The ScrumMaster in one of our teams is frustrated with the Product Owners because they are never present, and hardly communicate with the team except to shout at them when something critical needs to be worked on "yesterday".
The ScrumMaster has taken the ownership of the different Product Backlogs and joined them into a Team Backlog, where items for all products are collected.
In this example, the team has not enforced a Force Ranked Priority on the backlog or Sprint Backlog, which then leads to a more difficult decision on the real priorities for each item that ends up in the Sprint Backlog. This leads to the stakeholders, who are not engaged, classifying every item as Critical or High priority. This situation then leads to the team in practice deciding which items are done first and which Product Owners are served first.

See Also (patterns and anti-patterns not defined yet):

• Team Backlog
• Backlog In Shape
• Planning Meeting
• Secret Team Backlog anti-pattern

Pattern format explanation

In "Name" I give a name to the pattern.
In "Problem" I describe the problem the team is facing in the form of a root cause and a set of symptoms that may be detected and lead to this problem.
In "Context" I explain where the pattern is applicable.
In "Forces" I try to describe the constraints or forces that the solution has to take into account.
In "Solution" I try to describe the instructions and practices to be used to solve the problem as described.
In "Example" I briefly explain the case of one team at work that has faced this problem and how they solved it.