What takes the Project manager outside of the Scrum team?

Are you referring to the budgeting and strategic positioning of the product?

First a subtle but significant difference, the Scrum framework focuses on products. When people are having difficulties in understanding and transitioning, it can be helpful to look at each Sprint as a project. Within each Sprint, the scope is limited by the forecast of the Development Team. A result is that the cost is easily understood in these short iterations. By creating an increment which is potentially releasable, customer and market feedback can be gathered early and often. The role of the Product Owner can serve many of those classical project management functions.

For me the Scrum Master has to lead the Scrum framework: organisation of different types of meetings (daily, review...) and practices (planning poker, burndow chart, kanban...). But Scrum does not manage other tasks of "traditional" project manager: risk management, budget, steering commitee etc. So I think these are additional tasks for the scrum master (if the scrum master is the project manager too).

I agree with Alan. Budget is a Product Owner's responsibility and should be fairly straightforward.

Although I agree with Product Owner driving the strategy and budgeting aspects for a 'Product' in Scrum, most often than not some of the organizations get caught between a conundrum of sorts when stakeholder/business budget is holistically allocated and handled at much higher level (like Line of Business) than individual 'Project /Product'. Similarly, the IT/Technology partners budget are also handled separately thereby creating a disconnect or difficulty in presenting coherent metrics to stakeholders and upper management.

Interestingly enough, in these kind of setups- Product Owner and their organization hierarchy fall under Business partner's budget and Scrum Master would be under Technology partner's budget. This creates a tug of war between PO and SM in taking a budgetary call on 'who decides what gets to team and done in this year of releases and what gets pushed over'.

In these scenarios, Which role should take prime responsibility in budget?

Any insight would be much appreciated.

Cheers !

Scrum requires each project to meet its goals, expectations, project changes at the end of each sprint. Product owner, scrum master, and the team are three major roles in the sprint. The product owner should be familiar with all project development, business goals and customer needs. The Scrum Master should take responsibility that the team is on track in each sprint. Project Manager should take responsibility to complete plan and close project. He /she must find out the way to meet the product requirements.
He/she is also involved in project budgeting and the timeline required to complete the project. Project Manager has the main responsibility to share the budget to the highest level in an organization. So obviously, a project manager will be a part of each scrum sprint. At the same time, he will be handling the other aspects of a project outside the scrum team.

@Steffi

>> The Scrum Master should take responsibility that the team is on track in each sprint

Development Team is responsible to make sure everything is on track in each Sprint and not the Scrum Master. SM should ensure Scrum principles are adhered by scrum team and remove impediments in the process of achieving sprint goal.

>> Project Manager should take responsibility to complete plan and close project. He /she must find out the way to meet the product requirements.He/she is also involved in project budgeting and the timeline required to complete the project. Project Manager has the main responsibility to share the budget to the highest level in an organization. So obviously, a project manager will be a part of each scrum sprint. At the same time, he will be handling the other aspects of a project outside the scrum team.

There is no Project Manager role in Scrum.

I think what (to me) is always confusing about "Project Manager" is that (as we all know as it is repeated over & over) Scrum does not define such a role, yet there is likely to be such a role(s) somewhere around any Product development the organization undertakes. However, this role isn't managing the *project* of getting the Product Increments scoped and completed (responsibility of the PO and DT), nor is this role managing the Scrum framework and obstacles (the responsibility of the SM). Instead, the PM roles are managing all the other activities around releasing/integrating/using the Product Increment into the organization and its customers.

For instance, when the Product Owner elects to release a Product Increment, there are many activities and people involved in making that happen, and these are all outside the responsibility of the Scrum Team. Consider a Scrum Team in a large bank creating a product for use by their inbound/outbound Call Center. In this case, a PM might do the planning (scheduling, budgeting, staffing) and execution of such things as:

1. Creation of Marketing Materials, Press Releases, Advertising Campaign, Client notification letters
2. Conducting User Training (perhaps even additional staffing)
3. Coordinating launch with any third-party (or even internal) co-dependencies
4. Deploying the Product to all the centers and servers
5. Creating a fall-back plan (if the roll-out fails)
6. Creating a support plan, staffing & training the 24x7 support team
7. Notifying any government regulatory agencies, as required
8. etc, etc, etc, etc

Of course, many of these will require some cooperation and input from the Scrum Team. The PO would be involved in identifying which upcoming Increments are likely to be worth releasing, contributing to the marketing plan, etc. The Development Team may need to provide input to those planning the deployment, the fallback plan and the 24x7 support.

I am *most* anxious to hear feedback on this from others, because (IMO) this is the least-well addressed topic in Scrum. I want to see if others feel that the tasks I've assigned to a "PM" (outside of Scrum, but part of the organization's needs relating to making the Product useful) belong to the Scrum Team and, if so, how that is accomplished. Or, if they generally agree with what I wrote, how they handle the resulting dependencies on the DT for input/coordination.

Thanks!

> when the Product Owner elects to release a Product Increment, there
> are many activities and people involved in making that happen, and
> these are all outside the responsibility of the Scrum Team

If they are needed in order to create and release an increment, why would they be outside the responsibility of the Scrum Team?

A Scrum Team will engage in product development and in the empirical delivery of maximum value. Are any of the activities you cited irrelevant to this?

Ian, I was hoping that you would be a responder, as I think you have a deep foundation of experience and are quick to assist! This exchange has the potential to make it all "come together" for me, so I am looking forward to it.

You asked why I feel the noted activities would be outside the Scrum Team. Let me turn that around and ask if, on the projects (using that term generically) you've experienced, do your Scrum Teams travel the country training the end users on use of a "potentially releasable" increment? If so, does that training have to complete in order for that Increment to really be "potentially releasable"? How big are your Development Teams that allow them to dedicate people from each team to this constant training that might not actually be needed (e.g. in most cases in early iterations, a "potentially" releasable Increment won't *actually* release)?

Remember that the actual release, in many projects, is a very large effort. My last few projects involved perhaps 20 dedicated staff on the development teams, but had as many as 120 people (from various business areas, third-party providers, legal team, system support, data migration, backup & warehousing, etc) and an actual rollout involved sending mailing to the clients (two months in advance), taking out newspaper and radio ads, negotiating contracts and change orders with the affected third-parties, executing the push to all remote servers and configurations to databases, executing the migration of data from old format to new, and a round-the-clock 72 hours of rollout that had a continuous presence of at least 25 people. Not all projects are just introducing a few new screens.

So, in your projects does the Development Team do all the above, and for each Iteration?

In Scrum, with large-scale complex deliverables, multiple Scrum Teams may be needed to create a valuable and usable Sprint increment. They collaborate by means of a Nexus or Nexus+.

In a Nexus, each team is individually responsible for delivering a product feature which makes the increment potentially releasable. The Nexus is responsible for ensuring that all work, regardless of type, is fully integrated and tested by the end of each Sprint. Not all of that development work is necessarily coding work. It could certainly involve training end-users, given that the increment may not be releasable without it. It could even involve sending mail to clients and taking out ads, if that is needed for release, but since this is a matter of stakeholder liaison it is more likely to be undertaken or at least organized by the Product Owner. All of this work would form part of the increment if it is essential to its value and usage.

An important consideration when achieving this standard is to have a Definition of Done that encompasses *all* release qualities, regardless of whether they are technical or non-technical. This is because the critical concern is making sure that there is no undone work at the end of a Sprint. In Scrum there should be no work left to do after an increment is delivered, not even a mail-shot, if that work is needed to effect a release.

Ian, thank you for the response. Frankly, it isn't making sense to me yet from a practical perspective.

First, is the purpose of an Iteration to deliver a "potentially releasable increment" or a "released increment"?
I thought that the answer was *releasable*, not *released*. If so, there is always work to move it from the former to the latter. If an Increment is actually only *released* in a fraction of the Increments, then the work between *releasable* and *released* (which can be quite a large expense) is wasted on all the others, therefore not a good value return to the business. This includes many of the activities I noted above, from notifying end-clients, government agencies, creating marketing material (via ad agencies), training call center and support staff, ordering radio/tv/news ads and social media promotions, etc. Why would you do these public things (e.g. ads) before the PO has even decided to release?

If, in fact, the answer is actually *released*, then an Increment isn't "Done" until is is actually released. As the PO makes the decision about releasing in (or subsequent to) the Sprint Review, is your experience that she "pushes a button" (maybe not a real button, but I think you know what I mean) and it is instantly live with no further impact on the DT or others? If not, what does she have to do? In the Sprints in which she chooses to not release, are those Story Points not credited as accomplished for metrics, as they weren't released, but put back in the PB as incomplete? If all release activities fall to the Scrum Team and one legal (or other) requirement is for client notifications to go out 60 to 90 days in advance of a "release", yet you don't *know* that all PB items will be "done" that far in advance, how is that handled (reflected in the PB, moved to SB, notification actually sent, etc). In some cases, once clients are notified, there can actually be government penalties for not delivering when committed. Certainly we wouldn't want to go through that notification every Increment "just in case" when we know that not every Increment will release -- we'd lose clients and look foolish. And, if she chooses to not release, what activity is done (and by whom) to undo all the prep for the release (tell the trained people that it has been delayed, withdraw the advertisements, tell the regulatory agencies, etc)?

Please forgive my questions, but this is a very significant thing for me to properly embrace Scrum. I have bought into it as a great way of turning out Product that is "ready to go" (including the technical environment & release processes), but I just cannot see how it extends to "making it go" in the context of my questions above. Maybe I am missing a key point, and I hope you can educate me!

Thanks again!

If any work needs to be done by the Development Team before an increment can be released, then it is not potentially releasable. That may include training, advertisements, and notifications. Actual release should be dependent upon immediate business or market conditions. The essential principle is that there should be no delay (and thus no outstanding work to do) in responding to those conditions.

To achieve this ability, Scrum may require that certain assumptions regarding the interface between the product and its environment are challenged. The challenge is great because each and every Sprint Increment must be potentially releasable and with minimum attenuation of feedback. Everything you describe must be brought within a time-frame of no more than 30 days. The way teams work with stakeholders themselves is therefore *also* subject to transformation. That's the challenge of agility at scale.

For example:

- Certain stakeholders, including potential end-users, may need to be involved during a Sprint so they are familiar with the system being developed. This can mean building a new and very different relationship with them.
- Clients will need to be brought into a position where they can actually benefit from Sprint cycles and rapid feedback. Expectations about the scale of deliveries may need to change, along with time-frames which ought not to exceed one month.
- The scope of "notification" may need to be reduced. Instead of expecting a push of large releases, stakeholders should expect to be engaged more closely and more frequently, to the extent that release becomes a trivial act.

I very much appreciate your engaging in this exchange. While I think I understand what you are saying in theory, it isn't making sense to me practically.

First example is the notifications. In some of the projects I've managed, there is a legal requirement that clients (and government) be notified a *minimum* of 60 days in advance (I think the window also has a maximum of 90 days). As you write that everything must be brought to time-frame of no more than 30 days (I assume this number reflects the maximum Sprint length), either we must get the government to change its requirement, or we need to violate the law, or we make Sprints to be 60 days. None of these is going to happen, of course.

Second is that you write "actual release should be dependent upon immediate business or market conditions". OK, I understand this, but what is the effort of doing an "actual release". This has to reflect *some* work by someone somewhere.

Third, let me offer an example (I'll get away from banks and insurance companies, where most of my personal experience is) of a company deciding they want to make a new Spreadsheet product to compete with Excel and Google Sheets -- compatible, but much better. Obviously, they won't even have a fraction of a fully-compatible product in the first Sprint. If they are really good, their first iteration might produce an app that has a requisite framework (splash screen, legal notices, help function) and displays and navigates a sheet with 65K rows and 256 columns and allows input of text or numeric data into the cells, but no formatting, no formulas, no graphics. Now, maybe this is where I'm missing it all. Given that there is real "business" content in this iteration, I would have thought this was a good Sprint as it delivered business function (value). However, there is no way in which the business would "release" this to the world. So, in that sense, the business has no way to receive remuneration for its investment thus far. Does that mean that the Sprint did NOT produce an Increment of business value? If they needed to have this "releasable" (by the definition you offered above), then they would have contracted ad agencies, created marketing materials and a press release, paid for creation of packaging, paid for product to be created and stockpiled for delivery to retail stores, trademarked the name they are to use, gone to trade shows to promote its upcoming release, etc, etc. Who would *possibly* do these things on that Iteration (I'm confident they *couldn't* be accomplished in the first 30 days), especially when everyone knows that the Iteration is not going to release beyond internal "customers".

My struggle might be falling to two principles -- "releasable" and "business value".

Thank you again ...

Ian, BTW, if we ever find ourselves in the same city, I owe you a dinner ... :)

If there are legal requirements that would cause the attenuation of an agile feedback loop, then I suppose they may be challenged on that basis. A 60 day minimum is perhaps an interesting edge case, because it would be in line with the 2-month maximum that is asserted in the agile manifesto.

Release should involve a trivial amount of work. I'll leave it up to you to decide what trivial would mean in your case, but it should not impact the Development Team to a degree they would consider to be significant.

Release of an increment is not necessarily to the world. It must be to an environment where empirical evidence of value can be obtained. Scrum doesn't say much about how this is done, but the enterprise lean startup movement has given it a quite thorough treatment in terms of MVP's, cohort identification, and split testing.

Happy New Year everyone.

IMO the sprint release is a 'Fit For Purpose'. In Craig's spreadsheet example above it serves the purpose of data entry. The next sprint release could be the purpose of cell formatting etc. The Product as a whole can not be used as yet. When the decision is made that the product could be shipped (wrapped and packaged to be bought on the shelf so to speak) that release (the product release (say that happens after 15 sprints have been completed)) would be 'Fit For Use'. All the activities you mention would happen around this 'Fit For Use' product release. Can e.g. training material be created at the time of the 'Fit for Purpose' releases? It could. It would just describe the data entry and would evolve with the next sprints,

'Fit For Purpose' can mean that this 'building block' is developed, tested etc. and ready to be hooked in the end product when the time comes. e.g. building a house with pre-fab components. Every pre-fab component is ready to be used. It doesn't make a house fit for living yet.

'Fit for Use' is combining these pre-fab components to a point where the house-owner says I can move in. He/she might not mind that not all components are installed yet but as long as there are two bedrooms and bathrooms available they move in. That's a choice. The pre-fab kitchen comes in two weeks so they just get take-away in the meantime. The value for them would be that they don't have to pay rent somewhere else while waiting for the whole house to be completed. When the kitchen comes they know it will work from the moment it is installed. That work, including the testing of the appliances has all been done. They can go grocery shopping to fill that freezer when the guys are installing the kitchen. They know the freezer works so they don't run the risk that whatever they buy will go off.

I know this looks like a simple explanation but as Einstein said "“If you can't explain it to a six year old, you don't understand it yourself.” :)

Craig, I understand your dilemma and I have the same issue, how can a large product that is developed in 2 week increments have any ($) value to the business. It doesn't make sense in a practical sense.

If I buy a video game and it's functionality is drip-fed every two weeks then why would I even buy something like that?
When I buy it, the character can only jump up. After two weeks he can move to the right and jump up. After another 2 weeks he can jump over one obstacle. Etc. by the time I can play a real game, 6 months have past.

So this game has no value to me as the customer when I buy it after the first increment. I have to wait til this game is fully developed before I can enjoy playing it.

But does it mean that there is no 'business value' in the increments? Not a $ value as such. But there is value.
- seeing that character jump up and down and evolve through the increments is much more valuable than just getting a tick-box on a project plan 'character able to jump up and down' and 'character able to move to the right'
-demonstration and visualization give a much 'warmer feeling' than the tick-box 'milestone completed'. When my kids travel to Europe I love to see a selfie in front of the Eiffel Tower with a big smile. That gives me a much warmer feeling and confidence that everything is OK than an SMS saying 'in Paris now'.

Business confidence in the product and the methodology you're using to get there works in the same way. If you're able to give them 'a warm feeling' or the 'warm fuzzies' that everything will be OK has great value. If that can be accomplished with the 2 weeks sprint and a demo of what's done and works, then you're good.

I find it hard to come up with an example where the dollars start rolling in after a 2 week released product... and continue to flow in after another 2 weeks etc. And I certainly don't see customers lining up to buy such a product (like the video game I mentioned)...

So 'releasable' is more about the quality than about the usefulness. The quality is the business value in this case.