Welcome
Welcome to the first sprint planning in the series. I will be showing you which tools we use and we’ll go through the first planning process. We’ll define our goal for the sprint, the deliverable we want to have by the end of the sprint and the constraints we have to work with.
Just for the record the terms and phrases I will be using in this series are a combination of
- Personal experience working in companies where some agile was used.
- Essential Scrum by Kenneth S. Rubin
Trello
Alright, let’s start with our scrum board - we’ll be using Trello, but there is a plethora of other tools out there, so find the one that suits you the best - I personally like Trello because of its various integrations we will be using in the future. Especially the BitBucket one.
As you can see, I have created 4 lists - backlog, sprint, in progress and done. You might have also seen boards with “to test” or extra buffer layer “to do”. But let’s keep it simple for now. I also like the Kanban idea that a task should always move forward and never backward. That’s why I don’t have a “to test” list - simply because if tested and found not done - it would have to move back to “in progress”. But technically it’s always “in progress” until it’s done, so it’s just a matter of the process you have in place - for our case, it is not necessary to add extra layers of complexity.
Now that there are tasks in the backlog, it’s time to give them sizes. Usually there would be some triage or team debate, deciding the value of each task. But since I’m alone for this part of the project, it will have to be me, who decides. I will be using t-shirt sizes - S, M and L. Small meaning one to two hours, medium half a day and large the whole day. Anything bigger than Large has to be broken down to smaller tasks. Once done with the sizes, I will also sort them in the logical order in which they should be completed.
So, now we’re done with the so-called “backlog refinement” - organizing the backlog, making sure it has everything it needs. Now comes the time, when the actual planning takes place. Usually I would have a “budget” to spend and I would use that for fitting in as many tasks as possible. This sometimes feels like solving the knapsack problem, which is exactly what it is. You have tasks that have certain importance and time scope and you have a limited amount of time - so it is important to find the right amount of work so that you don’t have too many tasks, but you’re also never idle, because the tasks don’t fit - for example you finish with a smaller task towards the end of the day and the next task is a LARGE one - what do you do? Frankly, I just follow the advice I once heard at the WebExpo conference - Do What You Need To Do, To Get The Stuff Done.
I might have defined the scope of the tasks as S/M/L which should theoretically correspond to their timing, but the problem is that there is a lot of unknown. So, basically the first sprint will be a stepping stone for the next one, as we will have more data to derive our estimates from.
The first sprint will have 7 working days - I have encountered many variants of sprint planning, but to me, the best option is to have a maximum of two weeks, otherwise everybody loses focus. If the sprint is too short, it feels like there are just meetings all the time (planning, standups and retrospective) and nothing really gets done. If the sprint is too long, though, like a month - it feels more like waterfall development and the team loses the agility to pivot when needed. Also I’m factoring in the fact that some days of the two weeks I’ll actually be traveling.
So for 7 days of work, if everything has the right labels, it would amount to 7xL /14xM etc. It feels optimistic, but let’s go with it. After all this sprint is the initial one to gather data about our velocity.
| Name | Label | Assumed Size |
|---|---|---|
| Create git repository for Auth Service | Ops | Small |
| Create container for Auth Service | Dev | Medium |
| Create DB for Auth Service | Ops | Medium |
| Deploy Auth Service to single VM | Ops | Medium |
| Create git repository for Billing Service | Ops | Small |
| Create container for Billing Service | Dev | Medium |
| Create DB for Billing Service | Ops | Medium |
| Deploy Billing Service to single VM | Ops | Medium |
| Create git repository for API Service | Ops | Small |
| Create container for API Service | Dev | Medium |
| Create DB for API Service | Ops | Medium |
| Deploy API Service to single VM | Ops | Medium |
| Create git repository for Data Eater and Data Feeder | Ops | Small |
| Create container for Data Eater | Dev | Medium |
| Create container for Data Feeder | Dev | Medium |
| Deploy Swift Object Storage Service | Ops | Small |
| Deploy MongoDB Service | Ops | Small |
| Deploy Data Eater to single VM | Ops | Medium |
| Deploy Data Feeder to single VM | Ops | Medium |
| Create git repository for Web frontend | Ops | Small |
| Create container for Web frontend | Dev | Medium |
| Deploy Web frontend to single VM | Ops | Medium |
Total: 8.2 man/days
So this is the selection of tasks I believe can be done in the scope of this sprint. By looking at it, the overall theme of the sprint is “software packaging”. By the end of the sprint I’d like this things to be out of the way, so that we can put our focus elsewhere. As you might have noticed, there is no-devops in place - and do not mistake this with the no-ops initiative. There is no automation whatsoever. So hopefully in a couple of months we can get to something that at least somehow resembles continuous integration.
Wrap up
So, that’s all for the planning, ready for action. But let’s hear from you now - How do you do your sprint planning? Do you have a more rigorous process, or do you just eyeball it? Let me know on any social platform - facebook, twitter or instagram!
This post is a rewrite of the contents of the video that was published on YouTube and Facebook! 😎