The Importance of Pre-Project Sprints

31 March 2014


Introduction

In this article I would like to present the benefit of using Scrum at the pre-project stage. This presents an approach where the team can get used to Scrum early and is therefore ready to deliver potential product increments when the project starts.

Responding to change over following a plan

If you read this well-known value statement from the Agile Manifesto carefully, it says "following a plan" -- but not "planning in advance." This statement should not prevent a project manager from planning in advance. Many Agilists criticize the idea of planning. It looks like a crime to do even the minimum planning required to start a project. In this article, I would like to present a project manager's perspective on why minimum planning is necessary to ensure that the project will be delivered successfully.

Pre-project

In the beginning, someone has an idea or a need. This may result from new business objectives, responding to competitive pressures, changes in legislation, or a recommendation in a report or an audit. The trigger for the project could be almost anything. Prior to the activity to fully scope the project, it is important to verify that the project is worthwhile and viable. This necessitates the need for minimum planning even for an Agile project.

The need for minimum planning in Agile

Minimum planning in agile
 
As per the graphic above, there is a need for minimum planning even in Agile projects.

Introducing the pre-project sprints PQRS

Now that we understand the need for minimum planning, in this section, I present the concept of sprints PQRS to do the pre-project planning.

Sprint PQRS 

Sprint P

Goal:
Nothing should be done before defining certain basic information needed to make rational decisions about the commissioning of the project. Key roles and responsibilities should be resourced and allocated, and a foundation for the project needs to be available.

Objectives:
  • Sufficient information is available to define and confirm the scope of the project.
  • Individuals are appointed who will undertake the work required in managing and governing the project.
  • Lessons learned from previous projects are observed and examined.
  • Cost for the project and its duration are determined.

Sprint Q

Goal:
A key success factor of any project is that it delivers what the user expects and finds acceptable. This will only happen if these expectations are both stated and agreed upon at the beginning of the project, together with the standards to be used and the means of assessing their achievement. The goal of Sprint Q is to ensure that such agreements are captured and maintained.

Objectives:
  • To understand the customer's quality expectations and to check that the project's acceptance criteria, i.e., Definition of Done, are sufficiently defined.
  • To understand whether any corporate or program management strategies, standards, or practices relating to quality management need to be applied to the project.
  • To decide the tools and techniques used in quality control, the timing of quality assurance activities, and roles and responsibilities.
Example: Let me explain the need for this sprint with an example. Assume that you are manufacturing an engine for a diesel car in India. As per Indian government rules and regulations, the new engine must be sent to approval for various authorities, such as the Automobile Research Association of India, emission control authorities, etc. All these activities must be planned in advance, as they require budgeting, travel, and other costs. You can't plan them during/after the last sprint, when the engine is ready for use.

Sprint R

Goal:
Applying risk management procedure that will be adopted, the roles and responsibilities, the risk tolerances, the timing of risk management activities, the tools and techniques that will be used, and the reporting requirements are finalized.

Objectives:
  • To understand whether any corporate or program management strategies, standards, or practices relating to risk management need to be applied to the project.
  • How the performance of the risk management procedure will be reported.
  • Agreeing on the timing of risk management activities.
  • Defining the roles and responsibilities for risk management activities.
  • Defining the scales to be used for estimating probability and impact.
  • Defining early warning indicators to monitor and control risks.
  • To arrive at how a risk budget will be established and, if so, how it will be controlled.


Sprint S

Goal:
Ensuring a strong and solid foundation of the design required to deliver the Project's product is established. Necessary tools and techniques are identified and made available. Establish configuration management procedures. Establish the security controls required.

Objectives:
  • Defining the techniques, processes, and procedures to be used.
  • Defining the development interfaces to be maintained.
  • Defining the operational and maintenance interfaces to be maintained.
  • Defining the reporting, problem handling, and escalation arrangements.

Putting it altogether

Let me put all the pieces together and show how it fits.
Putting it all together 

Notes

  • Sprint PQRS can be shorter in duration when compared to regular development sprints.
  • Risk management and control is a continual activity. It is done during daily stand-ups and sprint reviews.
  • Quality management and control is essential for each sprint to ensure product shipment is meeting the Definition of Done.
  • I used the example of Sprint S for software-related projects.
  • By adopting Scrum even at the pre-project stage, the team would understand Agile better and would start working better as a team.



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1.5 (2 ratings)

Comments

Zach Bonaker, CSP,CSM,CSPO, 4/1/2014 9:44:47 AM
This is a nicely written and well illustrated article - I appreciate your contribution. Given this is Scrum Alliance, I'm going to assume that the article is written as a contribution to using Scrum.

With that said, I get the impression that this article is written from a traditional mindset and possibly hanging on a bit too tight to the familiarity of the plan-driven world.

Case in point: the article opens by suggesting that the Agile manifesto "should not prevent a project manager from planning in advance."

One, there isn't a project manager role in Scrum. We seek to empower people and advocate self-organizing, self-managing teams in Scrum.

Two, the interpretation of the manifesto here, to me, is misapplied. I don't know of any Agilists that argue against planning... in fact, introducing the Team to the next release through Release Planning is quite important (see Ken Rubin's "Essential Scrum" for a nicely written introduction to Release Planning). If I can be direct here, I will argue that Agilists argue against the size of planning that this article advocates... because, frankly, it is wasteful.

1. The "pre-project" activities described here, such as "alignment" and "value", are nearly identical to the responsibilities expected of the Product Owner role. There is no need to make this a process.

2. With a dedicated Scrum team, the complexities of resource planning (and budget) are simplified or outright removed. There is no need to make this a process.

3. In software development, the purpose of a sprint is to deliver a potentially shippable increment of software as part of the Product Owner's release plan. Here I see four sprints delivering no working software. In fact, it looks to me like the article has taken the structure of a sprint and mutated it into something unrecognizable... and I'm not sure why that was done.

What I see in this article is a heavyweight process likely tuned to large batch project management. When we deviate from large batch and adopt Lean principles, such as limits on WIP and small batches, our processes become simplified and waste is reduced.

This was an interesting article, but unfortunately, I just don't agree that the message is the right fit for Scrum.
Ron Jeffries, CST,CSP,CSM,CSD,CSPO,REP, 6/27/2014 6:10:43 PM
Scrum specifically requires a product increment, potentially shippable, at the end of every Sprint. These "pre-project" activities do not produce potentially shippable product increments. It's OK to want to plan ahead, although it is often wasteful if over-done. I would not be inclined to call these time intervals "Sprints", however, because they do not produce the most important Sprint artifact, the Product Increment.

You must Login or Signup to comment.