2
5 Comments

If you have experience with scrum/sprint planning, I need your opinion!

Holy wall of text!

There’s a TLDR on the bottom of my post, but if you’re interested in reading more about what problem exactly I’m trying to fix and how I’d solve it, then the full post is for you!

Hi everyone 👋

So what’s the problem?

I’ve been leading the sprint planning for the team at work for the past few months and while there are a huge amount & great tools out there to follow-up on the stories & bugs during the sprint, when it comes to the planning every two weeks it feels like a hassle. We’re using spreadsheets to calculate metrics like the working capacity for each team member, more easily matching our stories with this capacity, having an easier overview of the different projects,
etc.

Seriously, spreadsheets?

Well the thing is having these metrics is quite useful for the planning but this way of working consumes more planning time than it should in an agile environment because the spreadsheet requires manual updates before every sprint, the data from our HR & scrum tools is not easily refreshed, it still leaves a lot of room for human error and in general it’s already an overly complex spreadsheet and we’re still missing some valuable metrics like our sprint velocity & a bang-for-the-buck overview.

Now, we could just do away with the spreadsheets to spend less time on planning and simply talk about it, but the time saved would then open the door for more human error, forgetfulness, wildly inaccurate estimates, etc.. Perhaps I could convince my fellow developers, but that would be a hard no-go for management & clients.

It feels like we can’t live with it but also can’t live without it, so where do we go from here?

How could we solve it?

Since I was frustrated I started brainstorming on how we could improve our sprint planning, so I came up with https://startblock.io/ and wrote down my ideas there, long story short, it would make it easy to link up with your HR & scrum tools to easily get the working capacity for the next sprint(s), calculate the metrics you need with the least overhead possible & provide features to more easily involve the team to create better estimates & an achievable sprint plan.

TLDR; frustrated with the way we do sprint planning at work, using complex, time consuming & error prone spreadsheets to calculate the metrics we need to do a proper planning. Yet, we also can’t scrap the spreadsheets because it would open the doors for more human error, wildly inaccurate estimates & consistently under- or overplanning the team.
So I came up with https://startblock.io/ that would easily connect with your HR & scrum tools to import your data, calculate the metrics you need with the least overhead possible (e.g. working capacity of your team members, sprint velocity with projections, bang-for-buck overview) & provide features for improving team collaboration for more accurate estimates and creating an achievable sprint plan.

If you’ve got any feedback, no matter how harsh, I’d love to hear it! If you’ve had similar frustrations and you can see how this tool could solve them, then of course I’d love to hear that even more!

  1. 1

    Our sprint meeting ususally happens after PO has listed all the user stories and start to plan a sprint. We are using a tool called ZenTao which has open source verion.
    During the sprint planning our scrum master will direclty create the plan in zentao, and link all the stories which should be completed in this sprint, and reset the story priorit after the communication between po and the team.
    With a tool logging your work, it might be easier for you without explanation too much.

  2. 1

    My question is, "What is the consequence of getting sprint planning wrong?"

    In my experience in larger companies, sprint planning is usually used to try to get you within the right order of magnitude. There's a process that involves...

    1. Get a KPI to maximize, or a vision to fulfill
    2. Designer and PM generate project ideas and pick important ones by opportunity size
    3. Senior developers scope the work
    4. The PM prioritizes projects based on opportunity and effort
    5. Someone designs the project and splits it into tasks
    6. Every sprint, new tasks are dragged in by asking every developer, "Do you have enough work?"

    Assuming (0) as a premise, the steps with the biggest potential for problems are (1) being completely wrong on the opportunity size, or (2) messing up the project scoping. These are both usually wrong because of bad estimation. I think the sprint process is useful to apply downward pressure on the time that developers spend on tasks to encourage them to get help early and ship incremental changes ASAP without dawdling. But if a project takes 4 sprints instead of the projected 3 isn't that important. The important part was that it wasn't 30, and that the existence of sprints applied downward pressure on how long each developer took to complete these tasks. These are the things that outside observers of your team will really notice.

    So for you, I'd encourage you to really try to identify the pain that you're trying to solve. Why is it so important that human error be reduced in this area? What would go wrong if you spent less time doing this - is that the thing you're really trying to fix? Am I wrong about part of this, and there's really some inherent need to try to nail this with precision? What stakeholders in a company really need this to be correct? How do you connect with them?

    Good luck!

    1. 1

      Thanks for the great feedback!

      I actually started thinking about this out of my frustration so besides scratching my own itch I also got inspired by this Reddit post I made . Where on the one hand I noticed most responses mentioned that sprint planning should be fast & simple but still grounded in facts and on the other hand I read some people having the same frustrations as me.

      So having more accurrate estimates might be a byproduct, but what I really tried to focus on was a way where getting the facts is a straightforward & easy process to avoid a sprint planning becoming calendar tetris and enable more time for getting the team on board with the fundamental value you want to deliver & defining your goals.

      But I definitely can understand your skepticism and it's possible I might be getting caught by wishful thinking here, so next thing I'll do is reach out to Scrum Masters and simply talk about how they're currently tackling sprint planning to confirm if my idea would actually improve on that or solve any of their problems.

  3. 1

    We usually do our sprint planning using the tickets we have created in Jira directly. Because Jira contains the source of truth for all our work, moving away to a new platform to do the planning might not be ideal. However, if there is some sort of integration between Startblock and Jira, it could be interested to test it out.

    1. 2

      Indeed, it's definitely my goal to integrate with existing tools like Jira so the data is always up-to-date while also integrating with your HR tools to get the holidays or other non-working days synced up automatically as long as there's an API available for that.

Recommended Posts