Start your first Scrum project in 12+1 Steps

If you are serious about using Scrum, do not skip this. Bring an expert in to educate both teams and stakeholders, so you can start with the right foot. Experimenting with Scrum requires a mental shift, which cannot be triggered without an external facilitator.

The first step is to get your (internal or external) customer on board. If you have already discussed with them and they have understood how Scrum works they should be able to pick a Product Owner. Picking a suitable Product Owner is critical for the success of your project. This person has to be able to work on both strategy and details level, on both business and technical levels, on both senior management and junior employee level.

The next step is to have an initial description of the product or service you are about to start creating. High (epic) level, 10-20 user stories is fine at this point. This is normally something that the PO (Product Owner) is expected to do, usually with the help of major stakeholders (stakeholder = anyone who has an influence, or is influenced by the product or service that you’re developing) and the team.

Find the rest of the team. Picking up developers, keep in mind that you need to cover all skills required to turn user stories into releasable functionality. If your organization has a specialized QA (testing) department, make sure to get a person from there as well.

Picking up a Scrum Master might be trickier. Usually, during the Scrum training session you can usually spot 1-2 persons that seem to be more interested in the Agile way of working, or are excited about the potential that the team will uncover using Scrum. These will probably be the first Scrum Masters of your organization.

Co-location is important. The team will need to be in one place having ideally next to a cleared wall that they can use as their Scrum board. They should also easy have access to a meeting table or room for planning, retrospectives and other meetings.

The desk structure should promote collaboration. An idea is to have the team working back to back, so they can have easy access to each other screens just by rolling their chairs.

Like this:

Not like this

Based on initial backlog and assumptions the team creates the initial Architecture and System Design. They might need to consult with Architects from other teams or departments. This is also a good point to consult with security (always better to build security in the product from the start).

The architecture and design are not to be too detailed, as this can hinder change. They will emerge and reshape as the product evolves.

This might take a couple of days, or more, depending on the complexity and size of the Product Backlog. The team discusses and analyzes the backlog with the Product Owner and possibly some of the stakeholders, focusing on the most important items. Ideally, the output of this session should be an estimated backlog with identified dependencies (things expected to be delivered by people not in the team). There should be enough properly analyzed Product Backlog Items for the team to run 2-3 sprints.

The Sprint length (which should be kept constant) should be decided. It should not be too long, in order to avoid “waterfallising” the sprints and reduce the rhythm of delivery. Not too short, in order to allow meaningful value built in the increment. In any cases, it should be kept within the limits set by the framework (i.e. 4 weeks at maximum). Consider also organizational limitations or guidelines (e.g. Predefined release dates, shared testing infrastructure availability, etc).

The Definition of Done should include all quality checks needed to ensure that your product increment is ready to be delivered. It should include any possible organizational requirements (e.g. mandatory documentation, release preparation forms, etc.). It’s always a good idea to post it on the wall for easy reference.

Make sure everyone has all the tools and accesses they need, so they can focus on delivering value, instead of waiting for staff.

This is a great exercise, especially for a new team. Just map the required skills with the available skills. More than a reality check the skills map, will identify risks, and required learning paths for the team. This is a real life example:

Resource allocation forms, project initiation templates, … Fill-in everything you need to give your project formality. If your company operates under a strict waterfall model, this will not be easy as the waterfall bureaucracy usually assumes …well, waterfall. If this is the first Scrum project in your organization, it can be labeled as “Pilot”, which usually provides exemption from some of the compliance guidelines and as an audit candidate.

Get the team together and start your first sprint. You are ready to go!