When using SCRUM as an agile method for development, the first sprint (at least) will involve planning and requirements gathering, alongside user interactions.

When I search sprint backlogs, it usually contains items from the product backlog, such as:

  • Build a login system,
  • Build the home interface,
  • Design a database structure.

These always seem like design/implementation-based items, which I will not have in the first sprint or two (the only thing I have is the requirements specification).

In this case, what should I put in the sprint backlog?

Can I put items, such as:

  • definition of functional requirements?
  • definition of user stories?
  • discussion about the overall solution to the problem?
  • 3
    "the first sprint (at least) will involve planning and requirements gathering" I disagree with your assertion. If you don't have a backlog of items the dev team can work on, you shouldn't start a sprint. A project doesn't have to be Scrum 100% of the time. Commented Oct 28, 2021 at 16:13
  • 1
    @PhilipKendall: sounds like a good start for an answer
    – Doc Brown
    Commented Oct 28, 2021 at 16:13
  • @DocBrown I was more tempted to flag this to be moved to Project Management SE... Commented Oct 28, 2021 at 16:14
  • 2
    @PhilipKendall: come on, questions on Scrum processes are 100% on topic here - we should not just move questions to another SE site just because they could fit elsewhere, too.
    – Doc Brown
    Commented Oct 28, 2021 at 16:16
  • I think the important part here is defining a Definition of Ready. The first weeks are spent getting the first batch of user stories "ready." Commented Oct 28, 2021 at 16:19

3 Answers 3


I think Ewan has a good list of things to do and some good advice, but I'd like to focus more on the overall process.

Not every moment in the software development lifecycle needs to be a part of Scrum. While you can certainly create "developer stories" for things like setting up version control and continuous integration, your time is better spent getting "ready."

Getting ready involves much more than technical tasks. It involves coming together as a team to define your Scrum process. Starting the first user story assumes a number of things have already happened. These can include technical items like version control, servers and databases, but should also include Scrum-related activities like:

  • What is a user story?
  • How long is a sprint?
  • Do you release at the end of each sprint?
  • How often will you do backlog grooming?
  • What is your definition of done?
  • And most importantly at the beginning of the project, what is your definition of ready?

The definition of ready should include all information and design artifacts necessary to begin development of a story. Until you define "ready" the product team won't have a clue what the development team needs in order to begin work.

The myriad of technical tasks and setup required at the beginning of a project lends itself to a more task-based approach. Don't spend too much time pounding the square peg of project setup into the round hole of Scrum. Build your list of to-do's to get ready for the first sprint, then divide and conquer. Assign these items to individual team members where appropriate, and work together as a team on the things that affect everyone.

Just focus on getting ready in the most efficient manner.


Its impossible to tell you the best things to do in any given situation, but maybe we can point out some pitfalls to avoid.

I would say the key pitfall is worrying too much about the scrum process, estimating stuff and planning. You want to quickly get to a state where the project goals have been outlined and the key components and technology stack have been chosen.

Until you have something like, "It's an ecommerce website selling records with a nosql db and c# hosted in the cloud" Don't worry about the login story.

Once you have that you already have a tonne of setup work the devs can be getting on with while the more management/customer focused people can bicker about the colour of buttons. I mean, get on with roughing out happy paths and doing designs.

Once you get the components setup, ie Database installed and running, MyFirstWebsite deployed to dev env etc, you can then get into iterations of adding features. But until you are at that iteration stage you shouldn't worry about estimates, user stories, backlogs etc.

So to summerise, first items in backlog should be

  • mission statement
  • source control
  • servers
  • technology choices
  • outline of architecture

These should be obvious and basically already decided by the skills of your employees

Stage two

  • setup all that stuff
  • deploy hello world

Stage Three

  • while you were doing that we though up these initial stories go make em!

At the risk of being too simplistic, you put whatever stories in that need to be done. Don't overcomplicate it. If you literally don't have any stories written yet, do what many teams call a "sprint zero". A sprint zero is a chance for the team to come together to prepare for the first sprint.

Here's a good definition of sprint zero which you'll find on many websites:

Sprint zero usually takes place before the formal start of the project and/or at a team's inception. The goal of the Sprint is for the Development Team to come together to develop a minimal number of User Stories, project skeleton, story mapping, and develop a workable product.

You asked if you can put in stories such as "definition of functional requirements", "definition of user stories", and "discussion about the overall solution to the problem?". The answer is definitely yes. This is a chance for your team to get on the same page about what you're going to build and how you're going to do it.

Remember: scrum is a tool, not a goal. The goal of agile, and particularly scrum, isn't to create and complete stories, to generate a velocity, or to have retrospectives. The goal of agile is to build software. Scrum provides a framework for doing that, but scrum and its rituals should not be an obstacle. Do what your team needs to do to get the work done. If that means you take a week or two to build a backlog and define a definition of done, by all means do that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.