Skip to main content

Necessary activities before Sprinting

Last post 07:13 am March 15, 2019 by Ionut-Adrian Bejenaru
8 replies
06:45 am March 14, 2019

Hi everyone - need your help.

ATM I am working to kick off a separate initiative off the main product. We will work with different budget and team. Even though we intent to use Scrum and Agile methodologies for budgeting an scoping we still need to prepare before we are ready to go sprinting.

I am interested to hear your advice on - what is the sweet spot of just enough planning? We had to assemble our team, find a Product Owner, draft initial vision, choose and procure tools, estimate. Now, when should we say - alright, this is sufficient planning we need now to embark into empirical process control and begin sprinting?

I want to avoid stuff like Sprint Zero, Hardening Sprint, Architecture Sprint etc.

Thank you in advance.


07:21 am March 14, 2019

Hi Ionut-Adrian Bejenaru

Christiaan Verwijs had written an article in 2017 on kick-starting a great scrum team, I believe you can draw some inspiration and ideas from it.…

08:00 am March 14, 2019

Hi Cheng.

Indeed that is an awesome article. Christiaan is helping the community a lot. While that is putting light and details on how to engage with a newly form team - I am more interested and how we should cope as organization with the activities before that point.

As I said above - you can't go Sprinting from one day to another there are things to consider. I am curious to understand better when enough is enough, what is bare minimum to have in place before sprinting.


Thank you.

10:22 am March 14, 2019

As I said above - you can't go Sprinting from one day to another there are things to consider. I am curious to understand better when enough is enough, what is bare minimum to have in place before sprinting

It sounds as though you might be able to answer your own question. What are those “things to consider”? How do you know they are there, and why are they important?

Perhaps many of them are really just impediments to be overcome. The sooner sprinting begins, the sooner empirical process control can be established. It is hard (though not impossible) to make a case for putting EPC in delay.

11:14 am March 14, 2019


Like you asked 'what is bare minimum to have in place before sprinting.'

As per me 'A Team' which is ready to start the work.

Empiricism comes when more is known and that can only happen when you start the work.

Planning is never enough. 



11:43 am March 14, 2019

Hi all.

I always come here with questions and leave with confidence ;)

Thank you both Ian and Harshal. Indeed a team is all that is needed to start the EPC. And, the sooner we start the better. Perhaps I need to increase my tolerance to work with the unknown and uncertainty.

ATM I've been informed that we have the budget for the new initiative that we want to start. The team is already available to start.

What am I missing though and thus reluctant to start is:

- product backlog. Very first capabilities for the MVP;

- architecture comparative research. Perhaps we need to procure licences - don't know. We need to check with our budget this;

My doubt is: a) is it smart to park few days for a certain degree of preparation b) one team is ready jump into the Planning;

For the rest activities as team norms/ agreements, Scrum training etc. we can plan accordingly thought the Sprints.



04:05 pm March 14, 2019

How will you actually know that architectural needs you have until you start to build something that needs it?  As for the missing Product Backlog I ask this question.  How did you know that you needed a project to build something off the main product and that it should be a separate product backlog?  The answer to that question should be what is contained in your Product Backlog.  Details for it can be discovered through refinement.  The Scrum Guide says that refinement should take no more than 10% of the Development Team's time.  I tend to see that amount dwindle over time but for new "startups" it might take more.  How about having your first sprint be full of "spikes" that can be used to uncover things that could be impediments such as need for licensing, need for tools, shortage of skills in the Development Team, gaps in the information needed in order to build the product? That is very useful and valuable activities for the Development Team to undertake.

Back to this question I asked. How did you know that you needed a project to build something off the main product and that it should be a separate product backlog?  If it isn't actually a separate product but additional features for the main product, then you have a product backlog in existence already.  You have 2 teams work from the same backlog. But all of the information I mentioned before would need to exist in that backlog. 


08:59 pm March 14, 2019

Before the first Sprint begins, I would say there needs to be:

  • A Scrum Team
  • An understanding of the product to be developed

Before the end of the first Sprint Planning, there needs to be:

  • A definition of "Done" to inspect and adapt over the lifetime of the product
  • A Sprint Goal to inspect progress towards
  • A Sprint Backlog to inspect and adapt
  • An agreed timebox for the length of the Sprint (for the first Sprint I'd recommend defining the sprint length during Sprint Planning. If you follow the Scrum Guide literally, you would need to define it before the Sprint begins)

Before the Sprint Review, there needs to be:

  • A "Done" product increment to inspect
  • A Product Backlog to inspect and adapt

In many cases, it's therefore going to be possible to start straight away. The first Sprint may be difficult, and relatively inefficient, but it should lead to earlier empirical learning.

If you just go for it, and are conscious to do it effectively, you will quickly see what is missing, and can just build it as you go. For instance, as soon as a Product Backlog is needed (which would probably be as early as the Sprint Planning), the Product Owner should create it and start managing it.

Vision and architecture are important things to consider; although only to the extent that is helpful, and when the time is right. They needn't be bottlenecks that delay the first opportunities to develop working software, and begin getting feedback. If a lack of architectural knowledge then prevents the most valuable items from being delivered, the team should perform experiments or refinement that reduces this uncertainty to a manageable level.

07:13 am March 15, 2019

To be truly honest - I was afraid to start Sprinting and instill a sense of  'it's ok to not get things Done as we are uncovering architecture and direction'. In my mind I said - ok let's work on these first few blockers but once we start we start to get things Done. I agree it is a slippery slope, we may delay EPC too much.

Thank you Simon and all. With your addition to the mix I am confident that to we head into the right direction. In the end it is up to the team to decide.

@Daniel - we have the new initiative as a separate product as this is how it will be marketed. An add-on that can be bought with or without the rest of the modules.

Respect all!

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.