Generally, there are 5-10 scopes per 6 week project (6 six-week projects per year), and 1-20 tasks per scope. However, it is possible that scopes are more fine-grained, e.g., projects might have 25 scopes and fewer tasks per scope.
Using averages, assuming a scope takes 2 days, the maximum amount of scope you can have in a project = 15 scopes. And, assuming tasks take ~3 hours to complete, the maximum amount of tasks in a project = 80 tasks.
So, for example, a six-week project with 5 scopes = ~50 tasks; and 10 scopes = ~16 tasks.
Trying to apply a heuristic to manage scope hammering. Any thoughts on this logic?
I think you’re focusing too much on the numbers. Once you get into too fine details I dare to say that the numbers will fool you.
It’s often impossible from the start to say if a task will take 10 min or 2 days to perform as you don’t know which other challenges that might hide within the task. What looks easy and innocent somethings turn out to be hellish rabbit holes. And you should embrace this by giving the devs the freedom to not count hours.
We make a rough judgement of how much work is needed to accomplish something. And then we set an appetite that is close to that number. Then we combine project to the sum of 6 weeks and hand that to one team. That’s all the guidance we give them.
So we basically say: “These are the problems we expect you to solve during these 6 weeks. The appetite is an pointer on how you should allocate those weeks. But you are free to do things any way you like, as long as the problems are solved at the end of the cycle.”
I believe that going into more details than in the planning phase, before you actually start building, isn’t meaningful as the uncertainty is too high.
I agree. This was more of a way to think about things as they evolve during the build cycle, during task discovery, not pre-planning before the cycle begins. I would not recommend doing this exercise before starting (or, doing it at all…This is more of a measure of how much stuff might hypothetically exist in a six-week batch). Think of this logic as a way to help teams know if maybe things are getting too big or are not substantial enough. Does that make sense? I am interested in discussing if this is helpful. If not, why? Also, if it is useful, can anything can be done to improve this logic/thinking? If not, why?
I would probably focus on how many scopes get done and maybe not look too much at the tasks. My experience is that the devs tend not to document all tasks but rather just work.
But also looking at scopes one has to be careful as they can’t be seen as equal. Some scopes will require more work than other.
One would like to have a measurement of how many problems are solved for the users. This might be possible by adding user stories to the pitches and see how many are delivered at the end of the cycle. But here it also comes down to how the project is shaped. A good project gives the opportunity to solves a lot of problems with little effort from the devs.
We don’t currently have a good way today to measure if we improve our efficiency. I’m super interested to hear how other are doing.
Scopes are like anatomical parts. Their borders are natural, not arbitrarily imposed. You find them by feeling around for what depends on what and what can be finished independently. If there are too many, they won’t help you to have a map of the anatomy. If there are too few, they won’t help you to work on one piece independent of the others.