Necessary activities before Sprinting

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.

https://medium.com/the-liberators/how-to-kickstart-a-great-scrum-team-1…

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.

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.

Hi,

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. 

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.

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. 

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.

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!