Please support us by subscribing to our channel! Thanks a lot! 👏

Welcome

Sometimes…things get repetitive. But THIS? This never gets old. Let’s do the next sprint planning!

Welcome to the FOURTH sprint planning in the series. One could argue that now we should be pretty good at it. At least I hope. With the lessons learned from the previous sprints, we’ll attempt to estimate and plan accurately for the next sprint. We’ll go through backlog refinement, planning and define our goal for the sprint. The goal should serve as the shining beacon somewhere far away to enable us to steer in the right direction.

Trello

OK, let’s jump right into our scrum board - we’re using Trello, but you can use whatever you prefer or already have in your organization.

This is our trello board right after the last sprint review. So let’s start with the backlog refinement tasks:

1. As mentioned in the last sprint review - there were no freezeboxed issues, so no cleanup to be done there.
2. The tasks in “Done” lane need to be archived. Their done, so we don’t need to keep them there.

3. Undone tasks should be moved back to the backlog.

   You might say - “but you will work on them nonetheless”. Yes, but maybe not immediately, maybe there are new tasks needing our attention first and thus we’ll treat these tasks as equal to others and put them back in the backlog.

4. We need to add any new tasks/subtasks that arose after the last review.

   Just a reminder for tracking purposes we are dividing our tasks as dev and ops. To keep track of how much development vs configuration is done in the sprint. Development is green and Ops is blue. These colors were chosen arbitrarily.

5. We need to add new technical debt tasks we accumulated in the last sprint.
6. Last but not least - we need to re-validate the tasks that are already in the pipeline - if their size is appropriate, or whether or not they actually are still relevant and reshuffle those that are left.

There, the backlog is now like a brand new canvas, ready for us to make some art. But before we do, we need to set some criteria. In order to plan, a timeframe needs to be agreed. So the next sprint, just like the last one will have 7 working days. And as it is still only me working on these tasks, that will amount to 7 man/days available for spending in our sprint budget.

There are still tasks that depend on each other, so they come in pairs or tuples. But as we progress and accumulate technical debt, we will soon be able to mix and match the tasks and really perform the notorious knapsack problem - select the highest value in the optimal amount of time.

Planning

For those of you who haven’t watched our previous videos, we have estimates set to t-shirt sizes.

1. Small = 1 or 2 hours of work (0.2), yellow label
2. Medium = a half a day of work (0.5), orange label
3. Large = a day of work (1.0), purple label

With that in mind along with 7 days of work, I will now select the appropriate tasks to match our budget.

Tasks selected and sorted in the order in which they should be completed. I like the visual progress where some issues were rendered to be too vague or maybe even naïve during the initial planning back in sprint 1.

Name	Label	Assumed Size
Create container for notification proxy	Dev	Medium
Deploy notification proxy	Ops	Medium
Create container for URL test server	Dev	Medium
Deploy URL test server	Ops	Medium
Deploy Swift Object Storage Service	Ops	Medium
Deploy MongoDB Service	Ops	Medium
Create containers for CRON jobs	Dev	Large
Deploy CRON jobs as Cloud Run tasks	Ops	Large
Create container for resizing server	Dev	Medium
Deploy resizing server	Ops	Medium
Create container for export server	Dev	Medium
Deploy export server	Ops	Medium

Total: 7 man/days

As we move forward and get things done, we uncover previously unknown complexity, but also learn new things allowing us to move faster in similar tasks. A lot of the python code is in fact granular and divided into smaller services, which turned out to be the right move when it was first designed.

Goal

So the goal for this sprint is:

Enable persistence layer and deploy helper services in the Python clusters

This will be the criteria against which we’ll validate our success of the sprint in the next review. Not all the issues have to necessarily be done, there is some unknown - I haven’t left a lot of room for debugging - I’m being slightly optimistic. But in general we want to move in the direction of the goal and keep our focus.

Conclusion

And here we are - all done with the planning and as always - ready for action. But there is one more thing I mentioned in the review that needs to be added - schedule for the standups! And so it is - 10:15 AM CET. I am putting it on my calendar and I intend to stick with it for the entire sprint. Each day we will post on our social media to remind you we will be live, so feel free to tune in and ask some questions!

But let’s hear you now - What time is your standup? Is it the first thing in the morning? Or do you allow some time in the morning for your team to cleanup and structure their thoughts for the meeting? Let me know in the comment section below! Let me know on any social platform - facebook, twitter or instagram!