Being a Scrum Master can be challenging when you are planning the first Sprint with a
new team. Your responsibility is more than just adding the Sprint Events to everyone’s
calendar.
You’ll have to make sure that your team has the minimum of artifacts needed: Product
Owner, Developers, and high-level requirements.
You need the Product Owner to clarify the requirements for the developers. And you need
the developers to implement the requirements coming from the Product Owner. Which, of
course implies a set of requirements in place.
Are these 3 artifacts enough? Yes, but it’s not ideal for a successful first Sprint.
I have prepared for you a list of 4 artifacts that you’ll need in order to start your first sprint successfully.
1. Have a team of people with all the essential knowledge to deliver the product
In a Scrum Team, the Product Owner, Developers, and Scrum Master roles are indispensable if you want an effective Sprint.
Imagine a Scrum Team where there’s no one to fill in the Product Owner’s role. Apart from the fact you cannot call it Scrum Team anymore, you’ll see one thing occurring: the client has opened a direct communication channel with the Developers.
Where is this leading you?
- The team members cannot focus on the right things: The Product Owner knows what information to pass on to the team. And identifies what is just noise that interrupts their work. But when you work directly with the customer, a lot of information comes unfiltered to the team at any time.
- Delays in delivery due to lack of clarity: There are too few customers that know how to translate the business needs into a set of requirements.
- Priorities change during the Sprint: Customers are not familiar with the Scrum process. And they don’t invest their time in understanding it. Even so, I’ve seen customers asking teams to work with the Scrum framework without understanding its benefits or pitfalls.
What if you don’t have a dedicated Scrum Master on your team? Can the team still deliver value when the first Sprint ends?
Some teams nominate the Scrum Master role to another team member. Sometimes a developer, a tester, or even the Product Owner. But that person cannot focus equally on both roles.
Here are a few reasons you need a Scrum Master on your team:
- You need someone to teach the team how to work in sprints if they are not familiar with it. It can happen when a team is just put together for a new project and might have worked on other types of projects before.
- They’ll ensure everyone has all the required access to tools and environments. Chasing people to help you out with it can be a time-consuming thing to do.
And who will implement the Product Owner’s requirements if there are no Developers around? As you would expect, the Developers are the key part of the team.
Not having a Product Owner on the team leads to chaotic and unrealistic timelines. But without the Developers carrying out the work, there will be no deliverables in the end.
2. Define a Product Backlog with high-level requirements
The Product Backlog doesn’t have to be fully planned in the first Sprint. And don’t expect that from your future Sprints either.
While you develop the product, many changes will emerge because the market is in continuous movement. Furthermore, competitors always appear and you have to keep up.
How to manage your first Sprint without a detailed and ordered list of User Stories?
- Ask the Product Owner to prepare two or three working items with high-level details before you go into the first Sprint and discuss them beforehand. These items should be very simple and small pieces of work.
- Schedule a couple of Refinement sessions throughout the Sprint. This way, the Product Owner and Developers will have the chance to discuss in more detail future working items. It will help create items for the next sprint.
- Do not estimate the working items. When is it fine to do that, though? When the team has already built features for that product and they know the product very well.
Otherwise, you’re more likely to complicate future attempts to make estimations. Let the team get familiar with the product for the first two or three Sprints. And then use the Affinity estimation technique to create your baseline.
3. Schedule the Sprint Planning event
Before going into the Sprint, you need a Sprint Planning session to work out the way it will unfold.
What will you do in your first Planning Session:
- No Planning session can end without defining a Spring goal. And the team’s first Sprint is no exception.
- The team will organize their Sprint Backlog. At this point, developers can group to work together on one item. In the first few sprints, it’s recommended to collaborate on the User Stories. Working in pairs helps developers gather knowledge faster and easier.
- In the event of not having the possibility to gather a list of requirements and discuss them properly before the Sprint begins, the team can clarify the User Stories during Planning. However, it’s preferable to have a separate meeting before.
4. Get access to all the required environments
To get started, you’ll all need access to several environments and tools. This is a job that falls under the Scrum Master’s responsibility. It’s easier to do it if you create a ramp-up document, and keep track of every permission that was obtained and what is still pending.
What type of access you could need:
- Communication channels
- Development environments
- Testing environments
- Tools to write and test the code
- Tools for Scrum Master and Product Owner
If your team is working on a contract basis, these permissions are often on the client’s side. And you have to work with them to get all the access you need.
