The two largest project killers

In my opinion Scrum offers a number of advantages in maintenance:

• reliable financial forecasts, both for customer and supplier;
• reduced overhead in change management procedures and overall management costs;
• self organizing team with a lot of knowledge of the customers domain (which is crucial with a small team);
• fast delivery;
• last but not least; dealing effectively with unpredictability.

Actually, the advantages from a project point of view are also fully applicable to maintenance.

Strangely it seems that people revert to old habits. Scrum is applauded for the project’s success, but now ‘things can go back to normal’. I would argue that unpredictability still remains in the maintenance phase of the product’s lifecycle. I think this is where it goes wrong. People think that now the project is finished the problems are resolved and changes are small and can be managed effectively and cost friendly in the old manner.
That wouldn’t be my prediction

My main purpose was to provoke a 'paradigm change' since most people in the audience aren't involved in agile system development currently. So a large part of my presentation was about predictability and dealing with changes and why Scrum is a better approach to this then the traditional waterfall method. I remember clearly the first time I heard about Scrum a couple of years ago. My first reaction was that it couldn't work and only after a couple weeks I began to understand the strengths of the agile way of thinking.

We had some great discussions Thursday and I think I've been able to 'turn' some people. Mission accomplished

Why combining PRINCE2 with Scrum?

I think Scrum is great and we all should use the Scrum approach whenever possible. The ‘whenever possible’ bit does concern me. I’m not at all happy with the ‘implement Scrum as cleanly as possible and work from there’ approach. Sometimes the gap between reality and the ideal agile approach is too wide to bridge, which results in a failed project and frustrated people. It isn’t healthy nor productive and just isn’t necessary. (And also isn’t agile in itself).

I’ve learned by experience that there’s only so much change people can endure. A little bit of radical change so now and then is acceptable and healthy, but not too much in the same time frame and certainly some time is needed to get accustomed to the new situation. Implementing lean is also a lean process, an iterative process of change, learn and adapt.

So the first reason why I think PRINCE2 and Scrum combine very well is because people are accustomed to PRINCE2 and a PRINCE2 project management wrapper around Scrum makes the Scrum implementation much easier.
The second reason is because I think the PRINCE2/Scrum combination does add value to the customer.

That said, how in earth can a ‘heavyweight’ method like PRINCE2 be combined with a lightweight Scrum approach?

PRINCE2 is more agile than you think

PRINCE2 doesn’t have a great reputation in the agile world. PRINCE2 is anti-agile and applying PRINCE2 makes you an evil ‘command and control’ type of manager.

PRINCE2 actually is intended to be scaled down to the project’s context. The manual explicitly states that ‘right-sizing PRINCE2 is a critical success factor’. The 2005 version of the PRINCE2 manual doesn’t explain right-sizing PRINCE2 very well though. It’s written in a very formal style and (almost) doesn’t mention the choices you can make. This is where the bad reputation comes from. If you implement PRINCE2 straight from the book, usually very heavyweight, failure is imminent.

This all has changed with the 2009 version. PRINCE2 principles are introduced to explain what’s really important. The implementation of these principles is highly adoptable. The manual also clearly explains that PRINCE2 can be merged with other methods. This is because PRINCE2 is only a project management framework, it says nothing about delivery methods. PRINCE2 also isn’t waterfall. The word even doesn’t exist in the manual.

Positioning Scrum within the PRINCE2 framework

The Scrum process is all about delivery. Fast and effective delivery is key. Within PRINCE2 the delivery process is a black box. PRINCE2 is all about managing the project’s process.

This makes Scrum a natural fit to the PRINCE2 ‘Managing Product Delivery’ process. This also makes PRINCE2 the project management wrapper around Scrum. I think this is a great combination and I’ll explain this below with some real life problems we all have with Scrum. I’ll also explain some PRINCE2 implementation choices which are needed with the PRINCE2/Scrum combo.

PRINCE2 solutions to Scrum problems

The Product Owner ‘superhuman’

The Product Owner is the one and only person representing the customer. This person also represents all stakeholders. Frankly, it’s very, very hard for anyone to meet all the requirements for this job. It’s clearly one the most common problems we have with Scrum. There are some solutions, like the ‘proxy’ Product Owner, but PRINCE2 has a much more adult and proven approach; the project board.

The project board knows three roles: Executive (accountable for the business case), Senior Supplier (accountable for delivery), Senior User (represents the users, accountable for the product’s requirements). Usually the Senior User is represented by a user team on an operational level.

It’s very easy to split up the Product Owner’s responsibilities between the Project Board’s roles, it doesn’t change the Scrum process. It actually adds value because Scrum doesn’t cope well with customer/supplier projects where the supplier takes commercial risks.  That’s because the supplier isn’t represented in the Scrum process.

The project board doesn’t make a project more heavy weight. It might seem so but in real life you still have the same talks with the executives involved even when a project board doesn’t exist. The project board actually makes your life as a project manager easier because in PRINCE2 the project board is accountable for the project’s success, not you. This makes the board your ally in removing impediments, also because the board members usually have the authority to do so.

The CSM: responsible for the Scrum process, not for results

Most people don’t seem to know that a PRINCE2 PM is not accountable to the project’s outcome, the Project Board is. That’s why the project plan must be approved by the Project Board, that’s why all important decisions are made by the Project Board. PRINCE2 has introduced the concept of tolerances to make the project’s process more independent (management by exception). The fact remains that the PM’s main duty is managing the project’s process. That’s not unlike Scrum, where the CSM also isn’t accountable to the project’s outcome.

In my view both the PM and CSM have the same challenges and pitfalls. Managing the process and creating strong teams. The difference is that a CSM hasn’t authority over the team, the PM does. Sometimes problems arise in Scrum projects when the CSM exceeds his/her authority when trying to impose changes in the team’s process. Sometime problems arise in non-Scrum projects when the PM rules by ‘command and control’. Sometimes problems arise when the customer isn’t used to a self-managing team and expects more from a CSM then Scrum allowes.

In all cases it isn’t easy to create a focused and self managing team. IMHO being a PM doesn’t impediment the co-existence of a self managing team. There always exists boundaries of self-determination and a PM with the proper attitude and management style also is capable in creating an effective team. A difference is that the PM does have the authority to impose changes when necessary.

Of course in the combination PRINCE2 and Scrum it also isn’t a problem at all to have a PM with one or more Scrum teams, each having a CSM.

The project startup

There exists different views how to implement a Scrum project, especially the startup phase.

One approach is to ‘just start’, and manage the implementation impediments along the way. This shouldn’t be a problem, because impediments are expected and the iterative Scrum approach with Sprint Retrospectives is an excellent way of learning and adapting.

The problem I have with this is that during the first few Sprints a lot of impediments are to be encountered. I find it difficult gaining trust and confidence in a Scrum approach when a lot of ‘problems’ occur. In my experience managing expectations helps but isn’t enough. I prefer a preparation phase, sometimes called a ‘Sprint zero’.

Within PRINCE2 the preparation phase is an essential part of the method. The processes ‘Starting up a project’ and ‘Initiating a project’ are used to get approval to starting the project, based on a common understanding of the project’s business case, methods and procedures and also is important to get commitment from the people involved. This preparation phase doesn’t have to be heavyweight and can be executed quickly.

Trust

A traditional sequential approach offers confidence by predicting a delivery date, costs or a fixed scope. We all know that that won’t happen, but a commitment is given which is something a customer likes. Scrum doesn’t offer this level of commitment. There exists more uncertainties. Fixed date yes, but no fixed scope. Only after some Sprints the outcome becomes somewhat more predictable. It is something the customer has to live with. I’m not saying that this is wrong. I’m only saying that it’s difficult for a customer.

Scrum has some instruments that help, like velocity or the burndown chart. It still is an alien approach to most people, certainly during the first few Sprints.

I’ve experienced that a PRINCE2 wrapper around Scrum helps a lot in gaining trust, especially before or during startup. PRINCE2 is well known, the customer is accustomed to the instruments that PRINCE2 offers and the PRINCE2 process ‘Directing a project’ is a more explicit means to influence the project’s progress than the Product Owner tasks as described in Scrum.

Product Backlog

A problem with the Product Backlog is keeping overview. The list is very dynamic and contains all kinds of User Stories: small/large, different priorities, different business domains or processes. Also sometimes interdependencies exists (which shouldn’t but it happens anyhow).

I can’t help notice that the PRINCE2 technique called Product Breakdown Structure is useful in creating some order in the chaos. It’s not unlike other solutions I’ve seen explained in blogs.

Risks

Within Scrum there’s no explicit method for managing risks. Partly it isn’t a problem because a lot of risks are managed implicitly by delivering in short intervals. Each Sprint is a checkpoint in which both solution and process are discussed and improved. This is a very effective approach for problems inside the sphere of influence of the project.

In my opinion there is a problem with risks that lie outside of the team. The CSM is reponsible for managing these problems (impediments) but he/she has limited authority. Also it isn’t an pro-active aproach to problems. Problems should be managed when they are still risks. (Although a valid risk-countermeasure is ‘do nothing’, which can work with an agile approach).

The PRINCE2 approach with explicit riskmanagement and an active involvement from the project board to me works very well. It shouldn’t cost too much time and effort and can add a lot of value. The PM (CSM) can deal with risks/problems within the team’s process, the project board can deal with the other risks and problems.

Agile PRINCE2 implementation

There’s more to making PRINCE2 agile then described above.

Agile business case and Product Definitions

PRINCE2 nowhere states that scope is fixed or that the project’s business case is fixed. It’s perfectly allright working with an evolving business case. (Though most people seem to think otherwise, maybe because most people think PRINCE2 equals waterfall). There is no impediment here combining PRINCE2 and Scrum.
The agile approach is to start with a high-level business case and amend this business case after each Sprint. In addition to this you can also start with a single high-level product definition (like a Vision statement). For single products I use Scrum User Stories in stead of product definitions. The PRINCE2 format for a product definition is much more comprehensive, but most information is about the process of creating, validating and accepting the product. With Scrum/PRINCE2 it would be useless repeating this information over and over again in each User Story because it’s the same for each story. (Though in special cases the PRINCE2 format might be handy).

Tolerances

The PRINCE2 management approach is to manage ‘by exception’. At the start of the project specific boundaries (tolerances) are established in which the team team can move freely. The project board only becomes involved when there is danger that the project moves outside of these boundaries. This works very well with an agile approach. The tolerances for money and time can be fixed (no tolerance) where the tolerance on scope can be used to establish a minimal scope to be delivered, for instance all User Stories with a ‘Must Have’ Business Value.

Reporting

The new PRINCE2 2009 manual states explictely that templates other then the official PRINCE2 ones can be used for reporting, as long as you report what is important to your customer.  It is a good idea to use specific Scrum information like release planning based on Velocity and Product Backlog, Lessons Learned based on Sprint Retrospectives.

Sprints or Phases

Since Scrum iterations (Sprints) follow each other closely, there is no time to get a formal approval from the Project Board to start the next Sprint. PRINCE2 states that approval is mandatory for each next project phase. This really isn’t a problem, there are a couple of solutions.

You can execute several ‘technical phases’ (Sprints) within one management phase and in this way ask approval for several Sprints at once. My favorite solution is to agree on an implicit approval for the next phase. I use the Sprint Planning meeting as an informal approval for the next phase. The Sprint Backlog is my phase plan. During the first days of the next Sprint I deliver a phase report, describing the results of the previous Sprint and the consequences for the release planning. Also tolerances are useful here. When the Sprint results or release planning are within the boundaries approval can be obtained automatically.

Lessons Learned

Lessons Learned are essential for any effective project. This is the case with both PRINCE2 and Scrum. In a traditional approach lessons learned usually aren’t. That’s because when lessons are only discussed when the project is finished, it is of no use to the project anymore. There is a large difference when compared to Scrum. The project’s process for each Sprint remains basically the same, you have the same people on the team, so you have lots of opportunities to try out solutions and learn. I also make this process of learning explicit to the customer by reporting the Sprint Retrospective results in each phase report.

Conclusion

Scrum is a highly effective approach for getting results. It does take a lot of thinking, knowledge and wisdom to make the right choices when implementing Scrum. Implementing ‘Scrum by the book’ in my opinion won’t always work, because there are too many problems to resolve, the change is too large. The problem with changes is that you can’t change instantly to an ideal. Changes are done from reality and in small steps.

In the real world PRINCE2 complements Scrum very well. The team works with Scrum, the project manager largely works with PRINCE2. Both methods are compatible. The real advantage of the combination is that a PRINCE2 layer around Scrum makes it much easier for a lot of organisations to move to an agile approach and more successful project outcome.

One warning though. In 1.5 hours it isn't possible to explain all the details of both PRINCE2 and Scrum, so I didn't. I told a little bit about Scrum and almost nothing about PRINCE2. The presentation was mostly about the specifics of the combination. In other words, some knowledge on PRINCE2 and Scrum is assumed.

I’ll try to post an English translation on this blog somewhere next week.

I'll share my experiences combining PRINCE2 with Scrum and explain what makes this combination very successful. Also, we have reserved plenty of time for questions and discussions, so hopefully there is a lot of knowledge to be shared and 'lessons to be learned'.

For more details please see our Whitehorses website or the LinkedIn event.

• The Executive is accountable for the project's Business Case.
• The Senior User represents the people whom will use the product. He is accountable that the product meets the needs of these people.
• The Senior Supplier represents the people whom will create the product. He is accountable for the quality of the product.

The project manager is NOT accountable for the project's success. He is only accountable for managing the project's process. His job is to execute the plan agreed on by the Project Board. As long as the project manager does not exceed his authority the Project Board is very helpful. Why?

• Accountability is not transferable It just isn't so. You might assign other people within the project. The fact remains that if something goes wrong, the people which are accountable bare the consequences. Not the project manager but his boss, not the team but the supplier's director.
• Accountability creates responsibility The project manager executes the project plan as approved by the Project Board. If something goes wrong the Project Board has the resposibility and also the 'power' to help out. Problems shouldn't be the project manager's problem. In fact they are the Project Board's problems, because these people are accountable. A bit of an oversimplification maybe, the project manager still has problems, but the principle is sound and very effective.
• The Project Board process is mostly an informal process The 'Directing a Project' process within PRINCE2 describes a number formal documents and procedures. It describes only the formal part of directing a project. The formal part isn't that important and should be executed as light (agile) as possible. The real process take place informally, in meetings and discussions and only if needed ('management by exception'). So this process doesn't take much time if executed properly.

To me Project Boards are agile because:

• they are the ultimate impediment removers;
• they let me focus on the project's process;
• take only a little bit of my time, since the process is mostly informal and would be executed anyhow (if the Project Board wouldn't exist the same progress reports would be asked);
• the distinction between Executive and Senior User for me is a much better fit than only a Product Owner (however sometimes the Executive and SU role can be combined within one person);
• the Scrum scoping and reporting processes are a perfect fit from a Project Board point of view, so there's very little need to amend the Scrum method.

I've managed a PRINCE2/Scrum project for 8 months now and the Project Board is really helping me out when problems arise. It's great!

The business side of Scrum however is almost blank. Only assigning a Product Owner is not enough. There’s a lot more to projects than only the Product Backlog and ownership of the Product Owner. That’s why there is so much discussion concerning the implementation of Scrum. You do need to fill in the gaps.

The most obvious gap with Scrum is the management of stakeholders.

With Scrum there’s only a Product Owner. This task can be delegated to someone else (the ‘proxy Product Owner’) or to multiple persons. The problem here is that Scrum needs a ‘single wringable neck’, which is difficult when it’s not one person or when the actual ownership lies somewhere else.

Then there’s the problem of the differences in interests. PRINCE2 makes the distinction between Senior User and Executive. The Senior User is the ultimate user, the person whom will accept and use the finished product. The Executive is responsible for the Business Case. He needs to balance costs and benefits. (By the way, the Business Case is a gap in itself!). Only in small projects these roles can be combined, in that case the Product Owner is both. In most projects the roles can not be combined. That creates a problem with Scrum. A process needs to be in place to manage differences in interests.  Scrum does not have such a process.

Another example occurs with projects with a commercial customer/supplier relationship. If there’s some risk involved then the party whom bares the risk needs some kind of control. Not only on an operational level but also on the executive level. Scrum does provide some level of control with the Burndown charts and Product Backlog, but there’s no process in place to manage progress and issues on an executive level.

These gaps are manageable. Also there is not a single solution that fits all. A lot of Scrum Masters (or project managers) have found a lot of solutions to cope with stakeholders. For me PRINCE2 complements Scrum very well. I use Scrum for the Delivery process and PRINCE2 for everything else. The team doesn’t notice PRINCE2 at all, they use Scrum. The customer notices the differences compared to a traditional PRINCE2  project, but the main processes remain the same. So again, Scrum sucks at some areas but combined with PRINCE2, I couldn’t live without it.

However, in ‘normal’ PRINCE2 projects, I’ve seldom seen a real Lessons Learned session. Sometimes the project manager quickly creates a Lessons Learned document near the end of the project because the document is part of the deliverables. The actual learning doesn’t take place, not just because of the mindset at the time but also because the project is finished.

To be fair to the people involved it’s quite difficult to actually benefit from Lessons Learned when using waterfall or when using lengthy iterations. In what way can Lessons Learned from the design phase be applied to the build phase? If something has gone wrong you do feel the pain, but nothing can be done about it.

PRINCE2 argues that these Lessons Learned should be documented for future use, so that the next project might benefit. That may be true, but I haven’t seen it happen yet. Even if the documents are read, knowledge transfer by writing documents is quite useless. If the same people do the next project there’s a chance that lessons are learned.

What really matters in projects is transforming Lessons Learned to actions within a short time frame. Otherwise the Lessons are not Learned.

Here’s where Scrum comes in. When PRINCE2 is combined with Scrum it suddenly becomes easy to learn from mistakes. Here’s why.

• Each Scrum iteration is done by the same people, delivers the same kind of products and uses the same methods and processes. Lessons Learned from the previous iteration are immediately transformed to changes in the next iteration’s approach. Furthermore, the team can track problems and changes over multiple iterations and really improve things.
• Each day the team has the Daily Scrum meeting in which progress and impediments are discussed. It only takes a day to notice problems and (hopefully) there’s plenty of time to do something about it.

That’s one of the things I love about Scrum.

Based on a quick risk-analysis a month ago he concluded that project management was a high risk area  because of the combination of PRINCE2 with Scrum. In his view this was an impossible combination.

After an in depth analysis the last couple of weeks his final conclusion is that the ‘combination can work as described’. In fact, he stated that if we do what we say we do (and I can assure you, we do) that it ‘possibly is an effective approach’.

In real life it is an effective approach. We have been working with PRINCE2 and Scrum since March now and have trippled the project’s output and quality compared to the time frame before March (using waterfall). The customer is very happy with the results, the supplier is happy, the team is happy, we are all happy

But still, I’m pleased that it’s officially confirmed now, the combination can work. 

The method has not been changed, it’s the description of the method that has changed.
This new book emphasizes not the theory of the method, but the principles behind the method and gives much more practical advice on the implementation of the method.

In my opinion PRINCE2 is a very successful project management method, especially when combined with the agility of Scrum. It always has been a struggle explaining that such a combination is possible. A lot of project managers don’t see that combination. It’s either ‘command and control’ or ‘let go’. Finally it is PRINCE2 itself that explains the proper way of implementing the method.

Currently all the projects at my current customer are audited. I’m really looking forward to the discussion about my agile PRINCE2 implementation! I’ll keep you posted on that…

In an ideal (theoretical) world, the next iteration’s velocity should be the same (or slightly better) then the last one. In the real world this is not the case. One cause is the fact that people don’t work all the time. They go on holidays, become ill, need training, etc. and don’t distribute there time off evenly over all iterations. Less capacity means less products delivered means less story points delivered.

The difference between the projected amount of story points and realized amount becomes even larger when the sprint duration is short (for instance a week) and the team is small in size.

In the long run it probably doesn’t matter that there’s a difference between estimated and realized story points for a specific sprint, but that’s not good enough for me:

• I want the team to have an amount of workload that is realistic, is taken seriously and is something the team can commit to.
• I don’t want to explain to the customer the differences between projections and realization when I can avoid it.
• I need a more realistic planning for the near future when a specific release approaches. Estimating based on the long run doesn’t do the job.

That’s why I do both velocity planning and capacity planning.
This is how it works:

1. Each team member registers on a daily basis in Excel the amount of hours they have worked per user story.
2. And the end of the sprint I calculate the total amount of worked hours.
3. Dividing the amount of delivered story points by the amount of worked hours gives me the sprint’s velocity: man-hours per story point.
4. Before the next sprint planning session I determine the availability of the individual team members during that sprint and summarize that into the available man-hours. Then I divide the available man-hours by the velocity (expressed in man-hours per story point) and I have the amount of story points to be delivered by the next sprint.

Measuring and reporting of velocity in man-hours per story point in stead of story points per sprint is much more precise and more transparent. It makes it easier for me explaining the differences in delivered story points per sprint. It also helps me creating better forecasts and a more precise release planning. Furthermore, the team likes to have forecasts that makes sense and don’t mind the little amount of paperwork involved.

It’s very difficult to explain the advantages of Scrum when the customer is not used to “agile” thinking. Because Scrum delivers tangible results in short increments one could think it’s possibly better to let the results do the talking.

Here in the Netherlands the Prince2 project management method is widely used. Prince2 has a “controlled start” phase in which an elaborate project plan is created. Only after approval of this plan the project is started. Interestingly, this startup phase is considered to be a major success factor within the Prince2 method.

Is there any use for a controlled start when implementing Scrum?

May be it is a cultural thing (or maybe it’s me) but I find it very difficult to sell the Scrum approach without a project plan. On the other hand, I find it quite easy to create a project plan when implementing Scrum. Because the customer is used to Prince2 I create a Prince2 project plan (a so called “Project Initiation Document”).

When possible I use Prince2 terminology (like “Stage” in stead of ” Sprint”). I also propose a Project Board which isn’t a Scrum thing but complements Scrum very well.
The Scrum specifics like a “Product Backlog” or “User Stories” are also part of the plan.

This way the customer has a more “traditional” feeling to the Scrum process and it becomes much more easy to get things going.

I would argue that managing expectations is much more challenging than one would think and that a Scrummaster should spend a lot of time managing these expectations.

First of all Scrum (or Agile) project management is new to most people. 
The first reaction is either “that will never work” (it was in my case ) or “wow, this is great, we can achieve anything now”. 
Without previous experience expectations are not realistic.

To overcome the initial doubts sales people often tend to focus only on the positive aspects of Scrum.
The customer is told that the Scrum approach is more effective than a waterfall approach and delivers more functionality in less time.This is because within Scrum a multifunctional team works together and the focus is geared on the customers requirements and not on documents. This is also because the team has a very professional test process so that technical issues almost never occur. 
Furthermore the customer is told that they can change the scope on a detailed level anytime, almost without penalty in time, budget or quality. This is because a Scrum project has a rolling approach to analysis and design. Each new sprint the design is complemented with new features and changing features that are not documented yet do not cost anything.

There are a couple of prerequisites to make this statement true.

You need a disciplined team that can focus on the results of one sprint and makes that a team effort.
Usually the people in the team have not worked together before and need some time to become effective (Michael James, my Scrum trainer told me that a team goes through the process of “Forming, Storming, Norming, Performing”).

The test process within the team needs to be efficient, repeatable and generally on a highly professional level. Without proper “proof” that the solution created within the sprint is a good one that complies to both functional and technical requirements, there is a big chance that issues arise later on thus compromising progress.
Usually the test process is not that professional and lots of technical issues frustrate the learning process.

Both supplier and customer must be able to breakdown the solution in small pieces and work only on these small pieces. 
For both parties this is a big change in thinking. It is not what they are used to and even seems counterproductive (but isn’t).

Both customer and supplier must be able to delegate control to the team. In order to raise productivity the team needs the authority to make it’s own decisions (and also must be capable to).
Usually both project manager and business executive are accustomed to “stay in control” by using all kinds of formal procedures and documents.

Probably there are a couple more prerequisites….

The reality is that while it is very difficult to create a hyper performing team, a lot of the aspects described above also do occur with more traditionally approached projects and the agile approach still will be more effective.

The problem occurs when the customer expects a hyper performing team and only receives well performing results.

So what is the role of the Scrummaster in this?

One role of the Scrummaster is to advocate and monitor the Scrum process.
I think it is essential that realism is a big part of that. 

“No, the first few sprints probably will not deliver any tangible results… this is because we need to learn to work together and need to get our test process working”.

The Scrummaster must be able to communicate both the positives and the negatives of Scrum and still have a compelling story.
The team needs to know that they are given some time to get accustomed to each other and get a performing process together.
The customer needs to know that the start will be slow but that the team will make it up later on (and if not we will find out very soon and can do something about it).

First of all, let me ask you another question. “Do Scrum projects have a business case?”

Well of course they do. Every project has a business case. A “reason why”, a “justification of”, a specific goal. Sometimes a business case only exists in the mind of the business executives, sometimes an elaborate analysis has led to a business case document.

As stated in my previous post projects tend to align to the measurement system and it is wise to align the measurement system to the business case. The same applies to Scrum projects. It does not help when the business case is not defined explicitly.

Within the PRINCE2 project management method the business case plays an important role. Unified Process also uses a Business Case. Scrum doesn’t have it, but if there is really good teamwork going on then probably the business case is clear anyhow.

So, does a Scrum project need a business case?
I would say yes. It plays an essential role to maintain focus on what is important. Even when teamwork is great it still helps a lot. It also can help managing the customers expectations.

At the same time I think the Business Case should be agile. It is of no use to spend too much time on analysis or describing the solution. That would not be agile and probably not effective. To me an Agile Business Case resembles a User Story. It describes the need of the customer and defines the boundaries of the solution/product, it does not describe the solution itself.