How do you go about scoping a larger project at your software dayjob? You know the culture, people and project. You probably don't have anything beyond a rough product idea, a fixed deadline (of course) and you need to work out what the tasks will be, and what it will take to get the job done.
I'm not talking about agile push planning here per se, but a good old classic 6-month-style deathmarch project. The development will be broken up into agile pushes, but the question at hand is a scoping question - how large is the project, can we do it in the time allowed and what would it take?
I've recently been through such an exercise at work, and it is clear I have much to learn. I did talk about this with people and have a rough process that could use to guide myself the next time I am asked to make estimates.
1. High-level groups: Come up with clear groups for your task breakdown. Business and product folks will understand high level groupings. You will report effort against these high level groups, and do preliminary resource allocations at the group level, so if you can split these groups into interesting milestones, that is ideal. For example, if I was building a website the groups might be: site supports sign up, site provides basic value, administration toolset available, site provides complex value. We can talk about effort required and who will be assigned these tasks in the absence of complete detail. Be sure to know if the business needs particular items broken out as 'optional' high level pieces - this will allow them to get a feel for what the "crazy new idea" would cost, separately from the rest of the project. For example, the business folks might want to know the cost of having real-time chat support - in which case breaking that out as a high-level group will let them see the effort involved relative to the rest of the project.
2. Task breakdown: Do a detailed but not an anal task breakdown of each area. Capture the top-level areas in some detail, but don't breakdown too far or it gets harder to estimate or you get into fractional days - too much detail causes inaccuracy, strangely. Each task should be expressed in terms of a feature capability ("User can register for the site") or a noun describing a work product ("Secure Email Platform"). Nouns tend to be good for infrastructural work that cannot be described succinctly using capabilities. This means we tend to do detailed business case estimation and lump-sum engineering infrastructural estimation - which I like because for an in-experienced estimator such as myself one is often a better estimator of engneering work for infrastructure and need more detailed capability lists to appropriately cover unforeseen business requirements.
3. Estimation: Assign a number of days to each task. These should be done in linear one-person days. How long would this task take one person? The reason for linear one person days is to capture a sense of raw effort for the task. With raw effort numbers, we can roll them up into each high-level group and get a quick idea of what the "long pull" / critical path of the project will be. We can assign more than one person to the tasks and have rules of thum for how much parallelization will help. When estimating raw effort for tasks, it's often useful to think as 3 days as the lowest unit you will estimate to - if something takes less than that, you probably went too fine grained and need to generalize or group it with other tasks or estimate a few tasks as taking 3 days combined. It's not reasonable to get into fractional days during estimation.
4. Document your assumptions: As you estimate tasks, you will have specific ideas as to the nature of what your designs are, whether you depend on other business units, if you are assuming purchase of off-the-shelf or using open-source software etc. It helps to document what those assumptions are as you go through each of the tasks. Take free form notes where relevant. At the end of effort estimation, you can trawl these assumptions and quickly assemble and surface a list of team dependencies and other assumptions that can help your project leaders become aware of some details at a business level.
5. Ask for help: Include people who will be doing the work. Everyone needs to have input into the scoping process - especially if they are going to be working on the project. It's up to you to know whether you should get them to scope or have a stab first then ask for input: different people like involvement at different times in the process. Other people are the best way of plugging gaps and thinking of issues you had glossed over or missed.
6. Sit back and think: Revisit your work two or three times over the course of a few days to a few weeks. Letting time pass, challenging your assumptions and revising strategy is vital (if you have time) to working more efficiently. Recently in my dayjob I have gone through three scoping sessions based on different assumptions: I gave a premium "do it the right way" estimate, a "compromised reduced scope" estimate and a "barebones hack it out with throwaway work" estimate. This gives management a feel for the choices and flexibility they have, and also helps surface key questions to ask, and can help in resource assignment (by choosing the right set of compromises for the level of resources they can get).
7. Quick Project Planning "So will we hit the Date?": Business People love dates and certainty. So you have raw effort rollups into high level groups by now. But can you say whether you can hit the hard deadline? What would it take? How do you start addressing this? Like it or not, you've done alot of the project planning already, we are just resource allocation and date assignments away from a scheduled project plan. People need at least a strawman plan - they think better that way. So let us see how to do this last CRITICAL step - after all, this project plan is what will be seen first, we had better make it as accurate/truthful as we can.
So I love working with the groups here, assigning resources to each group and dates to each group. This gives you the Gantt chart. It's also easier to allocate people at this high level rather than each task. The goal here is to come up with a rough plan - if you end up using it it is wise to leave specific tasks up to the people involved anyhow.
So, you know how long it would take one person in terms of raw effort to complete the project solo. We simply need to assign one or more people to each group, get a sense for the inherent parallelization of each group and do a rough Gantt chart with start/end dates for each high level group. BUT WAIT: we have to account for a few facts before we take the raw effort numbers, resource allocations and come up with dates:
So, I come up with resource assignments for each group, then apply multipliers on the raw effort numbers in this order: vacation day buffer multiplier, then qa/cross-functional overhead multiplier, then capability of the team multiplier (are these your stars on these tasks?), then parallelization multiplier for the number of people.
You just then take the true time numbers as a result of these multipliers, and lay out the tasks in parallel as possible. You are constrained by group-dependency, resource dependency and logical progression of the project. You'll have to make some guesses as to when each group can start/finish with respect to other groups (this is crucial) but most often you can play it safe and only parallelize the obvious independent tasks. This will leave you with a strawman rough project plan, and a magical "we are done here" date that the business folks can mull over.
8. Do not get attached to estimates: People change their minds, assumptions can change, more scoping is uaually required. Even though you have put in hours of effort into the scoping, you will not win friends if you get too attached to one spreadsheet. The value lies in creating a basis for informed decision making - you have actually succeeded when you hear big questions and statements like:
Finally, as an engineer-cum-estimator realize that at the end of the day instead of being able to run a program and see your new feature working, you have to be happy with doing the best scoping spreadsheet you can write. Your metric of success shifts, and it is important for your psyche to remember that.
How do you go about scoping a larger project at your software dayjob? You know the culture, people and project. You probably don't have anything beyond a rough product idea, a fixed deadline (of course) and you need to work out what the tasks will be, and what it will take to get the job done.
I've recently been through such an exercise at work, and its clear I have much to learn. I did talk about this with people and have a rough process that could use to guide myself the next time this happens.
1. Come up with clear groups for your task breakdown. Business and product folks will understand high level groupings. You will report effort against these high level groups, and do preliminary resource allocations at the group level. For example, if I was building a website the groups might be database/domain object design, business layer work and UI design work. We can talk about effort required and who will be assigned these tasks in the absence of complete detail.
2. Do a detailed but not an anal task breakdown of each area. Capture the top-level areas in some detail, but don't breakdown too far or it gets harder to estimate or you get into fractional days - too much detail causes inaccuracy, strangely. Each task should be expressed in terms of a feature capability ("User can register for the site") or a noun describing a work product ("Secure Email Platform"). Nouns tend to be good for infrastructural work that cannot be described succinctly using capabilities. This means we tend to do detailed business case estimation and lump-sum engineering infrastructural estimation - which I like because for an in-experienced estimator such as myself one is often a better estimator of engneering work for infrastructure and need more detailed capability lists to appropriately cover unforeseen business requirements.
3. Assign a number of days to each task. These should be done in linear one-person days. How long would this task take one person? The reason for linear one person days is to capture a sense of raw effort for the task. With raw effort numbers, we can roll them up into each high-level group and get a quick idea of what the "long pull" / critical path of the project will be. We can assign more than one person to the tasks and have rules of thum for how much parallelization will help. When estimating raw effort for tasks, it's often useful to think as 3 days as the lowest unit you will estimate to - if something takes less than that, you proably went too fine grained and need to generalize or group it with other tasks. It's not reasonable to get into fractional days here.