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…