Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Let's suppose a customer comes to us, explains their needs in business terms and ask us to develop a software solution. The customer agrees to do it by Scrum.
How do we start a Scrum project?
For example:
There are a two things that need to be in place for a Scrum team to start sprinting:
The first few sprints will often involve a bit more backlog refinement than a more established team because the team will be trying to create a bit of a buffer in their backlog. There may also be some other activities like the team defining their ways of working, definition of done, etc.
It is also not unusual for the first sprint to have a 'hello world' feature delivery. That is a minor feature is delivered, but many setup tasks are completed (build pipeline, tooling, etc.).
In a nutshell: identify a Product Owner and then start with a Sprint Planning meeting.
There are two likely scenarios. Either the Product Owner (PO) or sponsor already has an idea of things they want; if so, document those on a product backlog. Or there is some discussion needed to establish the first things (not everything) that need to be done. A sprint planning meeting on the first day with the whole team, or at least a core team, present should be able to resolve some priority items to work on for the first week or two.
Keep the initial planning meeting and the initial sprint duration as short as possible. It's a common mistake to attempt to plan too much detail from the beginning or to start with sprints being too long. The product backlog can evolve through a process of backlog refinement as you go.
For software projects where you are unsure about sprint duration, I would suggest your initial sprint be no more than one or two weeks at most. Short sprints are much easier to plan than longer ones. The first sprint may not turn out the way you expect - so keep it short so you can "fail fast" if necessary. You can always make sprint 2 longer if you must.
For Sprint Planning, the Scrum Guide says you should have one sprint worth of prioritized Product Backlog items (stories) in 'ready' state i.e., fully refined and well understood by the team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
If you take this too literally, you will find yourself in this chicken and egg situation.
At the very beginning of a project I have run a Sprint 0. In this Sprint 0 the Product Owner (PO) outlines the project and business goals to the team. A product backlog is created mostly consisting of epics. The development environment is set up. Definition of Done is discussed among the team and agreed upon. The goal for the first sprint is developed. The backlog is refined to develop one sprint worth of prioritized stories with acceptance criteria and story points.
However, some purists may object to this approach saying that you cannot have a sprint without a shippable increment being delivered. If this is your concern, you can do a minimal 'Hello World' feature delivery as recommended by Barnaby Golden.
But the main point to remember is that Scrum is a lightweight framework. It is not prescriptive. Follow the spirit of Scrum and make practical adaptations as needed and inspect the results in your retrospective meetings.
A Scrum project starts with the first sprint. In order to start the first sprint, you will need a team and a backlog. The backlog is the easy part, most teams can start the first sprint with some random notes scribbled on a napkin if they need to. Assembling the team is usually the hard part unless you already have a team.
Scrum doesn't tell you how to gather a team or obtain your starting backlog. Having them is essentially one of the requirements of doing Scrum. Essentially this is like a recipe; the recipe to bake an apple pie will tell you that you need to have apples. It doesn't tell you where to get them, and it doesn't care if you bought them in a supermarket or picked them from your own tree. The recipe merely requires you to have them, because it deals with how you use the apples and not where you find them.
Scrum is designed as a recipe for turning your team and your backlog into a working product, but getting the ingredients is not part of what Scrum offers. These are business decisions. Scrum is not a guide for how to run your entire business.
When do we gather the team?
Before you start doing Scrum, because a team is one of the requirements for starting Scrum.
Should the product backlog be ready before we start? If the product backlog is not ready before the start, then we can't prioritize it and choose the things to be done first.
It should be "ready" in the sense that it contains enough information to get started. For many teams, notes from the original meeting with the client is enough to get started. Expanding the backlog will be one of the things taking up time during the first few sprints.
What should be done first and who needs to be involved?
Get the whole team together, grab the backlog and start the first sprint with a sprint planning meeting.
I'll also add in some of your questions from comments, since the answers to those mostly align with what I stated above.
When do we learn what technology stack we are gonna use?
At the very latest, during the very first sprint meeting, when the team decides on how they're going to turn backlog items into a working product. Practically, this is often decided beforehand. It could be the company ("We're a Java software company, so your tool is Java") or the customer ("I need this app that works for all my employees and we give all of them Android devices") But if neither of those have a strong opinion, the team will decide based on what they think the best way to tackle the backlog is.
When do we determine what developers we need?
Before you start doing Scrum, because the developers are part of the team and the team is needed to start Scrum. Determining which developers you want to get into your team is a business decision and Scrum will offer no real help. (Beyond stating that whomever you hire, the whole group needs to have all the skills to handle the project. Knowing when they do is tricky before you start, but it's more a general "three developers who can't design an interface is not a complete scrum team" rule)
But what the team is gonna do if they have only epics at the beginning?
Decompose the backlog into smaller stories and then work on those.
