I want to share a story with you.
For almost two years, I had the chance to be a Scrum Master next to being a developer. I already had a PSM I certificate from way back, I worked in multiple teams that already tried scrum and implemented some sort of interpretation of it. But before my current project, I did not get a chance of actually be a Scrum Master.
I learned a lot thanks to that role. E.g. How not to fall asleep during meetings. You simply have to facilitate them ;-)
But what I want to share with you today is an observation in estimating work and delivering results.
DISCLAIMER! I am only a Scrum Padawan, true mastery will probably come someday (or never, whatever), so for people who know a lot about scrum, this may sound like Paulo Coehlo’s level of wisdom. Apologies if it does!
I want to share a story with you. For a year or two I got a chance to be a Scrum Master next to being a game developer. I already had a PSM I certificate, I worked in multiple teams that already tried scrum and implemented some sort of interpretation of it.
I’ve got many good experiences thanks to that role. I learned how not to fall asleep meetings. You simply have to facilitate them;-) But what I want to share with you today is an observation in estimating
Scrum Teams often use Story Points to answer the question of how complex a task is. The theory always states to NOT calculate story points into hours of work (or assume that 3 SP is like a whole day, which many teams I saw do anyway).
The temptation is big, that’s why sometimes they don’t use numbers (e.g. from a Fibonacci-like scale of 1, 2, 3, 5, 8, 12, etc.) but t-shirt sizes or something like that.
I always considered it very abstract, not only to explain it but also to use it.
My team used to underdeliver when it comes to how much story points we had done by the end of a two-week-long Sprint, we did not look good when compared to other teams.
But one recent Sprint was different, we delivered twice as much, and that without a full squad!
In order to explain why we managed (in my opinion, of course) I need to make a digression.
Each month we made a deployment, and our deployments were very complex. The entire system consists of multiple services and web applications. It’s so complex, that we made an entire checklist in Excel that had almost 100 tasks to be done prior/during/after the deployment.
This time we did one thing differently — we turned excel rows with tasks into tasks in our Sprint. Instead of having two to-do lists, we merged them into one. These weren’t big tasks — 1 story point usually, sometimes even a 0.5.
When we saw the planned Sprint we were afraid we would not deliver the entire Sprint, again.
Flash Forward, wooosh — we delivered the entire Sprint if not more. The only thing we did not have was those big confetti-raining balls on the ceiling Ace Attorney style ;-)
Why we succeeded this time? My money is on the fact that a large number of tasks we had were estimated for 1 story point.
It reminded me that one should not convert stary points into hours.
But it also made me think differently about story points.
Sure, Story Points are about complexity, but I realized one has to look back and reinterpret the estimation. In the end, the number tells us two more things:
- how much you don’t know about the task?
- what is the amount of risk linked to this task? The first point seems obvious, doesn’t it? In fact the higher the number is the less it is an estimation, and more of an alert.
I heard about teams that will only start working on tasks once they broke them down into small ones (1 or 2 points tasks).
Some estimation tools I saw limit the number of estimation numbers to 5 (meaning: 1, 2, 3, 5), assuming that larger tasks are not ready to start working on.
Whether you’re planning a work project or a side project it is important to front-load your unknowns.
Write down the tasks before you start them and try to break them down into smaller tasks.
Each time you analyze a task think:
- what is to be done here?
- have you done similar tasks before?
- if not — do you know how to do it?
- what can slow you down?
- what do you have to learn to finish the tasks?
The simpler your task list becomes, the more achievable it is.
I write weekly on becoming a game developer and related (off)topics on my newsletter Wannabe Indie Gamedev.
Top comments (0)