Does a Scrum Project Need Sprint 0?

One of the most debatable topics in Agile especially Scrum is whether a team can actually deliver something potentially shippable in the first Iteration or Sprint. Some folks suggest a Sprint 0 while some oppose it as they feel it is against scrum principles.

The purpose of this article is to help you understand whether a Sprint 0 really makes sense or not…

What is Sprint 0?

Sprint 0 or Iteration 0 is technically the first iteration of an agile project but it is more used for getting the preparatory work done rather than actual development. It is like a feeder sprint for the scrum team and product owner to work together to understand the backlog, discuss the relative priorities, estimate the top priority items and get ready to work on the most important stories in the first official development sprint of the project.

Do we really need a Sprint 0?

Technically No.

Lets assume you are the scrum master and are starting a new scrum product development project. You are meeting the product owner and the scrum team on a Monday morning which happens to be Day 1 of your Sprint 1.

You and the team are probably new and have little to no idea about the product you are going to building. The product owner is probably still refining his priorities and the first few days of the sprint will go in the team getting to know each other. Unless you do a 4 week sprint, by the team they identify the top priority stories, estimate and break it down into tasks we are probably 50% or more into the sprint and will not have enough time to do any worthwhile development that can be shipped by the end of the sprint. Even in a 4 week sprint, it is highly debatable as to how much actual development the team would be able to do after they get the basics sorted out.

According to Scrum, a Sprint is time boxed and you have to mark the sprint as completed by the end of the sprint. So, chances are high that you will have many incomplete stories by the end of your first sprint.

By adding a Sprint 0, I took the delivery pressure off the team and spent the first few days building the team and working collaboratively on the backlog to understand what the team is going to build. At the end of sprint 0, we have a decent shape backlog and the team has a few user stories that they can start work when Sprint 1 starts.

How long would a Sprint 0 be?

Ideally a team would need anywhere between 1-2 weeks to get familiar with each other and get the preliminary backlog of work ready. So, I would suggest you plan for a 1 week sprint 0 if your usual sprints are 1 or 2 weeks in length and a 2 week sprint 0 if your usual sprints are 3 or 4 weeks in length.

Is adding a Sprint 0 to the release schedule really scrum or agile?

Going by technical definition of the methodology No, I don’t think so. Sprint 0 is more like a planning period where the team work out the details of how they can work together in the coming weeks/months. Since, scrum doesn’t explicitly recommend a planning phase for a project and expects us to cover everything within the sprint, we cannot say that our project is doing scrum if we add a sprint 0.

At the same time, Agile is an adaptive mindset and approach where the team is free to tweak their processes to enhance their output. By adding a sprint 0 the team is basically improving the efficiency and delivery capabilities of sprints 1 and beyond so, I would say that even if we add a sprint 0, we will still be doing agile if we follow the other core principles that agile was built on – customer focus, regular delivery of value, adapting to changes and continuous improvement.

Real life scenario:

In real life agile projects, you can also find teams that use a stabilization or regression sprint toward the end of the major release where the team will make sure all bugs are fixed, pre-existing functionality that was delivered as part of the last major release are working fine and the product meets the quality standards set forth by the organization.

Again scrum & agile purists will argue that adding such an iteration is against the scrum methodology.

Yes, I cannot deny that. But, practical usability and fitness for purpose always trumps idealistic processes. If I am delivering a major product version to a customer, he would be more concerned about my project team delivering a quality product rather than following scrum perfectly. So, going by customer focus as our teams main goal, we are using one sprint to make sure the product is fit for use and delivering the same to the customer and I would still say that my team followed agile methodology because we did follow all the agile principles.

What are your thoughts on sprint 0 and a stabilization testing sprint? Sound off in the comments section…

Can Product Owner also be the Scrum Master?

One of the most common points of stress in a scrum project is when the same individual gets assigned more than one role in a scrum team. As you may have seen in the article titled “Participants in Scrum” each role has its own responsibilities and often times the roles clash with one another. In this article am gonna highlight why I think the roles of a scrum master and product owner should not be held by the same individual.

Reason 1: Different Purpose

The two roles couldn’t be any more different than they are now. They are both focused on different aspects of the project. The product owner spends his time thinking about what the next product increment should be and how to liaise with key business stakeholders to understand their needs. The scrum master on the other hand is thinking about how to motivate & help the team to deliver the last increment that the product owner requested and how he can remove the impediments in the teams way.

If you are from a software/IT background, I could add an analogy here between a developer and a tester. Even though a developer can do testing and a tester can do coding, there is a reason these two roles were separated. When we test our own code, a sense of confidence creeps in which hinders the testing effectiveness. Whereas, when we are testing someone else’s code, our instinctive sense of doubt prevails and we are able to find much more bugs on the code.

Get the picture?

Reason 2:  There is always conflict between the two roles

As scrum master, one of my regular activities was negotiating with the product owner whenever he/she feels the team is just not taking the new story they created mid-sprint or one of the good to have stories for the upcoming sprint. The role of the product owner is to ask for more and more stories to be included in the sprint while the scrum master tries to protect the team and make sure that they don’t overcommit themselves while they continue to deliver good quality software sprint after sprint.

This means, these two roles are going to be at cross-hairs frequently and keeping the two roles separate means either party can do justice to their respective roles.

Reason 3: They are probably busy with their individual roles already and adding another role will overburden them

Even though the roles of a scrum master and product owner may sound simple on paper, trust me, it is a lot of work and both of those parties (in a typical scrum project) are probably quite busy doing their respective tasks and adding another role would overburden them. Even if they manage to burn the midnight oil and try to do multi-tasking, it will definitely affect their productivity & efficiency

Reason 4: Team and/or Product suffers

The scrum master is the guardian or protector for the team and is always protecting them from unwanted noise & distractions. A scrum master who is also the product owner might be biased toward adding more & more scope items to the product/sprint backlog and in the absence of a dedicated guardian the team will be exposed to a massive backlog which they will be constantly overloaded with. This will result in reduced velocity (with multiple WIP stories that get spill-over to the next sprint), reduced quality and more importantly reduced team morale.

On the other hand if the individual is more scrum master and pushes back on all new requirements, the product backlog and the organizations product as a whole will suffer while the team will be quite happy and satisfied.

A good scrum project is one where we are able to balance between keeping either demands at appropriate levels and not let one side overpower the other.

Note: It is practically impossible for the same individual to do 100% justice to both roles simultaneously. Bias and impact on the team or product is inevitable.

What are your thoughts on the same individual being both scrum master and product owner? Sound off in the comments section…

Organizational Influence on Project Management

If you are someone who has played the role of a Project Manager in more than one company you would know that the organization has a direct influence on how projects are managed. I have worked as a Project/Program manager in a few companies and I can vouch for this fact. 

In the PMP Exam series there were 3 articles that covered this topic and I have explained in great detail about how Organizational structure & culture impact projects. 

They are: 

• Organizational Influence on Projects 
• Understanding the Organizational Structure
• Enterprise Environmental Factors and Process Assets

Trivia: Some people use terms like Cultural Norms when they talk about an Organizations Culture. 

ORGANIZATIONAL STRUCTURE

Organization structure is the hierarchical relationships of various entities within the organization that collaborate with each other for project execution. Different organizations, by virtue of their objectives and core philosophies, carry different organizational structures. The structure of an organization determines the operational model used in the organization. Organizational structure determines the responsibilities for different functions and entities. 

You could refer back to the article titled Understanding the Organizational Structure to know more details because I don't want to repeat the same details once again. 

FUNCTIONAL STRUCTURE

The structure of a functionally structured organization is based on the functions performed by each component of the organization. Such organizations would have different departments that are responsible for different functions and the Project Manager would work with all those departments to get the project done. From the view point of a Project Manager, this type of organization is the hardest to execute projects. 

PROJECTIZED STRUCTURE

The structure of a projectized organization is based simply on the projects the organization executes. It follows that project managers have complete responsibility over all projects assigned to them. They are provided complete authority to define priorities, use resources, and direct and monitor work making this the best organizational structure for us to execute projects. 

MATRIX STRUCTURE

The matrix structure effectively combines the best attributes of the functional and the projectized structures. 

In a matrix-structured organization, team members report to both their functional managers and project managers. Effective management of this dual relationship is critical to overall success of the project. Thus, matrix structures require clear cut role definition. Also, team building in a matrix-structure organization is often difficult because of the dual reporting structure.

Depending on how close the Matrix Structure is, to either the Functional style or Projectized style, it can be categorized into 3 groups: strong matrix, weak matrix, and balanced matrix 

Strong Matrix

In organizations with strong matrix structures, project managers have greater authority or right to command than functional managers. Such organizations closely resemble those with projectized structures and have full-time project managers and full-time administrative staff for projects.

Weak Matrix

In organizations with weak matrix structures, project managers do not have as much power as functional managers. In a weak matrix, the role of a project manager might be more that of a project expediter or project coordinator, and, as a matter of fact, no official designation as “project manager” exists. The project expediter acts primarily as a staff assistant and communications coordinator and is not authorized to make or enforce decisions, whereas the project coordinator has moderate decision-making powers and reports to a higher-level manager.

Balanced Matrix

In organizations with balanced matrix structures, the powers of the project manager and the functional manager are about equal and in balance. Here, although the need for project managers is recognized, the project manager is not provided full authority over the project and project funding.

COMMON SUCCESS CRITERIA FOR ORGANIZATIONAL STRUCTURES

No matter what sort of Organizational structure your company is following, certain things need to be taken care of, if you want the proposed methodology of handling projects to be successful. Some of them are:

1. High Transparency
2. Strong Management Support 
3. Continuous Monitoring
4. Clear and On-time Communications 

If an organization can take care of the above 4 aspects, chances of their projects succeeding go up considerably. 

ORGANIZATION PROCESS ASSETS

Organization process assets (OPAs) are assets of an organization involved in project implementation that can be used to influence project success. Organizational Process Assets is just a fancy term for documents & templates that your company uses as per the project management & governance structure put forth by the PMO. Read this article about OPAs as I will be skipping the details and move on to key specifics quickly. 

Updating OPAs is generally the responsibility of the project team members as only they would have the complete details of the work they do especially those related to technical artifacts.

OPAs are grouped into two categories:

1. Processes and procedures
2. Project knowledge base — knowledge repository where filled-in templates and other data are available

Examples of process assets include formal and informal plans, procedures, processes, guidelines, “lessons learnt,” and historical information. Generally, OPAs appear on an organization's intranet site, so that team members can refer the procedure or process easily. Such an intranet may also carry filled-in templates and documents from other projects for reference. 

ENTERPRISE ENVIRONMENTAL FACTORS

Enterprise environmental factors are factors that surround or influence project success – basically the environment in which the project is being executed. Of course, they may have a positive or a negative influence on project outcome. These factors are used as inputs to the planning and initiating process because a project cannot be planned without analyzing available infrastructure, tools, and software. 

An organization's structure and infrastructure are good examples of the enterprise environmental factors that would govern any project management initiatives the organization may undertake. For more info on Enterprise Environmental Factors read this article from the PMP Exam series.

That wraps up the basics of Project Management related topics. The next section would deal with basics of Agile Project Management