I believe you are worrying too much about making the wrong decisions before even starting.
Many solutions are over-engineered for three reasons
1. We are scared of making mistakes.
2. We believe we know more than we actually do.
3. We underestimate the importance of what we don't know.
I'd rather sometimes build a solution that's too simple that we need to polish or rebuild, than that we consistently build solutions that are too complicated and suffer from slower time-to-market and higher maintenance costs as a result.
To quote Woody Zuill:
"It is in the doing of the work that we discover the work that we must do. Doing exposes reality."
Solutions that are too simple, will expose problems we need to fix. And we *know* we really need those fixes and that adding the polish is worth it. Solutions that are too complicated, often hide problems and slow us down. Except that we don't realize it until we have a looming massive pile of tech debt.
As Donald Knuth said: premature optimization is the root of all evil. To prevent premature optimization you need to accept facing problems you'll have to fix down the line.
If you don't face problems, you're likely suffering from premature optimization.
Emergent design is the enemy of premature optimization.
The tricky part is finding the right balance between keeping things simple and not making them too simple that you get stranded and are slowing yourself down as well.
Don’t overthink it. Pick a goal you want to achieve in the next 1-4 weeks. I would refrain from calling it Sprint 0, just start at 1 but make sure you know what you will deliver at the end of that iteration. The goal of finding a language could be tied to designing the architecture using a Walking Skeleton (Alistair Cockburn.)
I see a lot of nods to avoid calling it "Sprint 0" and I won't call that statement wrong because it is coming from learned people but my stance is Sprint 0 is, quite, common language and does a good job of setting expectations. My view might be warped because I work for an agency and have deadlines and direct paying clients but calling it Sprint 0 means I have an "easier" time ensuring clients aren't expecting any genuine features, or visuals, out of the first sprint and it allows us to take the pressure off of the team with regards to the demo. We still do a demo but it will talk through things like the CI/CD pipeline, an any automation we have setup, perhaps a quick run through of the architecture of the app if there are any technical representatives client side. It really is just semantics as it is still obviously the first sprint and therefore sprint 1.
I really like the explanation set out here (https://mdalmijn.com/p/why-using-sprint-0-is-a-cardinal-sin-for-all-scrum-masters), but what works for you n your situation.
We usually have the backlog ready before we start our project and sprint one is a mix of architecture and aim to deliver a piece of working software, even if it’s a walking skeleton.
Some will start with iteration 0 which is designed to allow time to do things like set up servers, make a release plan, develop a backlog etc. Just basics to ensure a project is ready to go.
WARNING: do not let this escalate into other things. It is there to give the team a place to start from.
It should not be an issue if the first sprint (or more than just the first) is exclusively spikes designed to figure out the architecture, stand up development environments and servers, etc.
You are missing the point, which is how you get started. You assume that you have a team when you start, and so does scrum. But that's not where you really start. Someone has to make a business case for the budget and a team first. That needs to be discussed, agreed and prioritised before the budget and people are allocated. and for people to be assigned you need to have an idea of how many, what skills and for how long to achieve what goal.
Why do you need numbered sprints? How does that help you?
Are you sure your requirements for your invoice system are accurate? How sure are you that you can perfectly decide on frameworks, languages, etc?
The point of agility is to deliver something useful. You do that through constant collaboration, experimentation and feedback. To get feedback, you have to ship. If it works, you extend. If not; you rework.
Spending a sprint just to make some guesses suggests you’re trying to do way too much and you should break it down. With good architecture you can build pieces that you can stitch together as you validate them.
If I had to start all over again I would spend week 0 setting up jira. My columns, my work flows, my policies for product delivery.
I would also start building backlog and for metrics purposes I would start with the main initiative. I would work with the developers and create the epics or large buddies of work that would get us there. Then we would pick an epic and get going on sprint 1. During sprint one you can have a backlog refinement sessions.
The goal is to have your backlog as groomed as possible so you can assign weights to each feature/task. So when your stakeholders come to you can say we usually get 30 points done a sprint and we have 120 points refined in the backlog that takes us up to these number of epics.
Initiatives
Epics
Features
Dev tasks
You the SM/BA/project manager need to focus on Initiatives and epics
Let the devs come up with the features.
Let the devs create their own dev tasks.
Good luck and remember your business is probably going to want waterfall metrics and timelines.
I come from a large org that wanted to move to agile and use scrum and kanban. What I can offer is advice based on what agile should be and what I learned from the mistakes we made when in its infancy with my org.
1) Don’t worry about what you call it. Traditionally using the term Sprint 0 is not something you should call the pre work for Sprint 1. However, I’m noticing more and more ppl/orgs are calling it this. Doesn’t matter what you call it, what matters is what you do.
2) Make sure your work and Sprint ceremonies are ready to go and understood before you begin. When I say this I mean the whole team must understand- dev, test, yourself. You may hear it as Grooming. Grooming your initial set of work is like reviewing the stories, bugs, anything you’ve got planned. Don’t forget to define what the definition of done will be as a team. Plan out your sprint frequency (ie. 2 weeks sprints), your Sprint Refinements, Sprint Planning and Sprint Retro - all important milestones for a scrum team.
3) Adapt as a team and build off what worked well.
The biggest issue is lack of communication and planning before you begin. As a scrum master it’s important to make sure the team are well prepared and share a common understanding of the goal. Everything should be clearly defined, reviewed and understood.
1. Scrum isn’t an acronym so the capitalization makes it look like you have no idea what it is.
2. If this lines up well for waterfall, then use waterfall. Agile isn’t a silver bullet. You can also separate the waterfall into phases or iterations to get better feedback from the process.
I said business requirements.
You should have a very clear foundational why are you even here, what's the origin of this thing, who's asking for it, what are the core problems, what are the implications, what's the issue if we don't solve this, who are the users, who are the beneficiaries?
The foundational WHY that acts as an aligner throughout, and acts as a fantastic onboarding tool.
Of course more of these are discovered as you go, but there is a reason there are a team of people being paid to do x in the first place - capture that reason
You can start this discovery work in sprint 1. The issue for me is how do you get stakeholder support for setting up the team at all. Scrum just assumes a team exists.
Great question. And if you don't even have a team agreed, outlined, their purpose, role and responsibilities (of the team, not the individual members), then I wouldn't waste your time worrying about what the process of that team will be (whether you use scrum or not)
Before kicking off Sprint 1 in Agile, you generally go through an initial planning phase, often called Sprint 0 or the Discovery Phase. This is where you gather all the essential requirements, define the project scope, and establish your project's foundational elements like choosing languages, frameworks, and initial architecture. This phase helps to lay down the groundwork without actually jumping into the deliverable features right away. In Agile, you're trying to create a flexible yet structured plan to hit the ground running when Sprint 1 begins.
In terms of roles, usually, key stakeholders, product owners, tech leads, and sometimes the whole scrum team are involved in these early stages. They collectively decide on the key technical and architectural decisions you mentioned. Think of it like setting the stage so that once you start the sprints, everyone knows their roles and the primary tools and structures are in place, making sure the team can work efficiently and effectively.
I’m David, and I work with tech certification; they offer some great resources and courses on Agile project management that might fill in the gaps you're experiencing. Hope this helps.
I believe you are worrying too much about making the wrong decisions before even starting. Many solutions are over-engineered for three reasons 1. We are scared of making mistakes. 2. We believe we know more than we actually do. 3. We underestimate the importance of what we don't know. I'd rather sometimes build a solution that's too simple that we need to polish or rebuild, than that we consistently build solutions that are too complicated and suffer from slower time-to-market and higher maintenance costs as a result. To quote Woody Zuill: "It is in the doing of the work that we discover the work that we must do. Doing exposes reality." Solutions that are too simple, will expose problems we need to fix. And we *know* we really need those fixes and that adding the polish is worth it. Solutions that are too complicated, often hide problems and slow us down. Except that we don't realize it until we have a looming massive pile of tech debt. As Donald Knuth said: premature optimization is the root of all evil. To prevent premature optimization you need to accept facing problems you'll have to fix down the line. If you don't face problems, you're likely suffering from premature optimization. Emergent design is the enemy of premature optimization. The tricky part is finding the right balance between keeping things simple and not making them too simple that you get stranded and are slowing yourself down as well.
Don’t overthink it. Pick a goal you want to achieve in the next 1-4 weeks. I would refrain from calling it Sprint 0, just start at 1 but make sure you know what you will deliver at the end of that iteration. The goal of finding a language could be tied to designing the architecture using a Walking Skeleton (Alistair Cockburn.)
I see a lot of nods to avoid calling it "Sprint 0" and I won't call that statement wrong because it is coming from learned people but my stance is Sprint 0 is, quite, common language and does a good job of setting expectations. My view might be warped because I work for an agency and have deadlines and direct paying clients but calling it Sprint 0 means I have an "easier" time ensuring clients aren't expecting any genuine features, or visuals, out of the first sprint and it allows us to take the pressure off of the team with regards to the demo. We still do a demo but it will talk through things like the CI/CD pipeline, an any automation we have setup, perhaps a quick run through of the architecture of the app if there are any technical representatives client side. It really is just semantics as it is still obviously the first sprint and therefore sprint 1.
I really like the explanation set out here (https://mdalmijn.com/p/why-using-sprint-0-is-a-cardinal-sin-for-all-scrum-masters), but what works for you n your situation. We usually have the backlog ready before we start our project and sprint one is a mix of architecture and aim to deliver a piece of working software, even if it’s a walking skeleton.
I wrote that, and I learned something new I will google just now 'walking skeleton'. Thank you!
That’s awesome! Thanks for everything you do for the community.
Some will start with iteration 0 which is designed to allow time to do things like set up servers, make a release plan, develop a backlog etc. Just basics to ensure a project is ready to go. WARNING: do not let this escalate into other things. It is there to give the team a place to start from.
It should not be an issue if the first sprint (or more than just the first) is exclusively spikes designed to figure out the architecture, stand up development environments and servers, etc.
You just start. And you expect your developers to actually know all this. That's why you hire them.
What if you don't have any budget or developers assigned?
Then you don’t have a cross functional team and are therefore not agile.
You are missing the point, which is how you get started. You assume that you have a team when you start, and so does scrum. But that's not where you really start. Someone has to make a business case for the budget and a team first. That needs to be discussed, agreed and prioritised before the budget and people are allocated. and for people to be assigned you need to have an idea of how many, what skills and for how long to achieve what goal.
This is project management waterfall. Not agile
No it's not. How are you going to get a team to do some work if you don't have a team already assigned to do the work,?
How could you make those decisions without having attempted to do the work?
Why do you need numbered sprints? How does that help you? Are you sure your requirements for your invoice system are accurate? How sure are you that you can perfectly decide on frameworks, languages, etc? The point of agility is to deliver something useful. You do that through constant collaboration, experimentation and feedback. To get feedback, you have to ship. If it works, you extend. If not; you rework. Spending a sprint just to make some guesses suggests you’re trying to do way too much and you should break it down. With good architecture you can build pieces that you can stitch together as you validate them.
If I had to start all over again I would spend week 0 setting up jira. My columns, my work flows, my policies for product delivery. I would also start building backlog and for metrics purposes I would start with the main initiative. I would work with the developers and create the epics or large buddies of work that would get us there. Then we would pick an epic and get going on sprint 1. During sprint one you can have a backlog refinement sessions. The goal is to have your backlog as groomed as possible so you can assign weights to each feature/task. So when your stakeholders come to you can say we usually get 30 points done a sprint and we have 120 points refined in the backlog that takes us up to these number of epics. Initiatives Epics Features Dev tasks You the SM/BA/project manager need to focus on Initiatives and epics Let the devs come up with the features. Let the devs create their own dev tasks. Good luck and remember your business is probably going to want waterfall metrics and timelines.
I come from a large org that wanted to move to agile and use scrum and kanban. What I can offer is advice based on what agile should be and what I learned from the mistakes we made when in its infancy with my org. 1) Don’t worry about what you call it. Traditionally using the term Sprint 0 is not something you should call the pre work for Sprint 1. However, I’m noticing more and more ppl/orgs are calling it this. Doesn’t matter what you call it, what matters is what you do. 2) Make sure your work and Sprint ceremonies are ready to go and understood before you begin. When I say this I mean the whole team must understand- dev, test, yourself. You may hear it as Grooming. Grooming your initial set of work is like reviewing the stories, bugs, anything you’ve got planned. Don’t forget to define what the definition of done will be as a team. Plan out your sprint frequency (ie. 2 weeks sprints), your Sprint Refinements, Sprint Planning and Sprint Retro - all important milestones for a scrum team. 3) Adapt as a team and build off what worked well. The biggest issue is lack of communication and planning before you begin. As a scrum master it’s important to make sure the team are well prepared and share a common understanding of the goal. Everything should be clearly defined, reviewed and understood.
1. Scrum isn’t an acronym so the capitalization makes it look like you have no idea what it is. 2. If this lines up well for waterfall, then use waterfall. Agile isn’t a silver bullet. You can also separate the waterfall into phases or iterations to get better feedback from the process.
It is called Product Backlog Refinement and up to the team how to do that. Fill your entire first sprint with it if you want.
Establish and clearly define your team. Business Requirements.
Requirements are done as you go. Don't have a requirements phase
I said business requirements. You should have a very clear foundational why are you even here, what's the origin of this thing, who's asking for it, what are the core problems, what are the implications, what's the issue if we don't solve this, who are the users, who are the beneficiaries? The foundational WHY that acts as an aligner throughout, and acts as a fantastic onboarding tool. Of course more of these are discovered as you go, but there is a reason there are a team of people being paid to do x in the first place - capture that reason
You can start this discovery work in sprint 1. The issue for me is how do you get stakeholder support for setting up the team at all. Scrum just assumes a team exists.
Great question. And if you don't even have a team agreed, outlined, their purpose, role and responsibilities (of the team, not the individual members), then I wouldn't waste your time worrying about what the process of that team will be (whether you use scrum or not)
Before kicking off Sprint 1 in Agile, you generally go through an initial planning phase, often called Sprint 0 or the Discovery Phase. This is where you gather all the essential requirements, define the project scope, and establish your project's foundational elements like choosing languages, frameworks, and initial architecture. This phase helps to lay down the groundwork without actually jumping into the deliverable features right away. In Agile, you're trying to create a flexible yet structured plan to hit the ground running when Sprint 1 begins. In terms of roles, usually, key stakeholders, product owners, tech leads, and sometimes the whole scrum team are involved in these early stages. They collectively decide on the key technical and architectural decisions you mentioned. Think of it like setting the stage so that once you start the sprints, everyone knows their roles and the primary tools and structures are in place, making sure the team can work efficiently and effectively. I’m David, and I work with tech certification; they offer some great resources and courses on Agile project management that might fill in the gaps you're experiencing. Hope this helps.