Meeting the deadlines and expectations of software projects depend on properly scoping features, algorithms and dependencies before touching any code. This is the step-by-step process Sizwe Ndlovu, Head of DevOps at Pineapple, and his team follow - with a project planner template you can download too!
Before Sizwe’s teams touch a single line of code, they proactively follow these five steps in order to scope the project or feature request in detail:
5 Steps to Scope a Project Well
- Define the final product
- Map the feature’s journey
- Match your needs to your resources
- Define edge cases and “code-reds”
- Modularise your team’s roles
What each step looks like
1: Define the final product
Before doing anything else, Sizwe says that it’s crucial to understand and be able to communicate what the end goal actually is. Otherwise, he’s found that you risk development going on for a lot longer than it ever needed to:
“What tends to happen… is that you end up working on a feature or product forever, because it’s just never finished… because you actually didn’t have a clear definition of what the final product looks like.”
It helps you define what you actually want to achieve, and guides the way you scope the rest of the project. It also helps keep the guidelines or ‘brief’ of the project within the realms of possibility, and prevents external requests being - in Sizwe’s own words - “dreams that can’t come true.”
A ‘hack’ to make it effective:
He’s found it most effective to phrase this as one sentence, something as simple as “This product/feature must do this and this.” He says it’s really important to keep the language simple and ‘human’, and check with whoever the client is (be it the business, or someone external) to make sure that this is what they want the product to achieve.
From that sentence, you can begin to start breaking up the smaller components of what that looks like practically, and what you need to get there.
2: Map the feature’s journey
Once the one-liner end-goal has been drafted, Sizwe says it’s useful to move on to defining, point by point, what you are trying to achieve with that final product. He describes it as looking something like this:
“Plan out your algorithm. What is it that it’s supposed to do? Then you can start breaking it down to bullets: ‘In order for this to do this function, it needs this information, and this information has to be sent to this endpoint, and that endpoint has to get other information to do this.”
A ‘hack’ to make it effective:
Sizwe says a clear, concise bulleted list is the best way to achieve this, with columns that answer the following questions:
- What does this product/feature need to do?
- What information does it need to do that?
- Where does that information need to go?
- What else is important for this to work?
Once the “journey” of that feature has been mapped-out, Sizwe’s teams are better able to see where they need to go, what they already have, and how to marry the two together in a way that sets them up to win.
3: Match your needs to your resources
Once Sizwe’s teams have a better idea of how the product or feature looks, they compare what they need to achieve for each of the various components, to the resources they have.
To illustrate what this looks like, Sizwe uses the example of a user inputting their details into a standard information submission feature:
“So, we need our database to understand that we need these fields, which are going to be said in this specific table or collection (and depending on which database you’re using, you need to capture the name, surname, whatever). Having agreed on that as a team, you also know that you need an endpoint to save all of these things.”
By systematically laying-out one’s needs and resources, Sizwe says it’s much easier to scope out what work still needs to be done. You can clearly see where you still need to add, adjust, or plan, and can factor that in to the development process before you even start, rather than things cropping up during development that then need reactive action before you can continue.
4: Modularise your team’s roles
Over and above a modular approach to one’s code, Sizwe emphasises modularising at a team-level as well: “Get people working on these things separately, so they can just move and do things. Otherwise, it’s really hard to get someone to work on this thing without drawing it out first, without separating everything that everyone needs… Because now, you might be in a position where one person can’t continue because they need something from another person first.”
With a good understanding of the new things that your feature needs, what endpoints you need, and what you need to accommodate for in the front end, you’ve already mapped-out a role for your front end person, and you’ve got a role for your backend person to start doing things.
“From that, you’ve already scoped out that whole feature. You know who’s going to work on what and - more importantly - they can work separately without each other.”
A ‘hack’ to make it effective:
To do this, Sizwe takes the functions and features he’s mapped-out previously, and begins looking at his team’s strengths to assign various roles and tasks. This also helps his team anticipate which edge cases and bugs they might run into, according to where and what they’ll be working on.
5: Define edge cases and “code-reds”
Sizwe finds immense value in setting aside time during project planning to discuss possible edge cases and “code-red” bugs. By defining these things as a team early on in the process, everyone is better able to identify them if they come up, has a plan-of-action to follow in addressing them, and won’t be slowed down by reactivity.
“That’s also one of the long-term effects of not planning in the first place,” Sizwe says, “because when these things come in the way, in most cases you don’t have a choice but to stop and attend to them, because they’re affecting users in production.” Reactive development leads to slower development, and risks a backlog of bugs and errors piling up.
Weeding out all of those edge cases during planning means you don’t have to do it during your sprint: “It will throw your guys off,” he says. “It’s never the best thing, because you tend to want to zone-in on that thing and finish it,” which takes away time from the thing you set out to do in the first place.
A ‘hack’ to make it effective:
For Sizwe, this has been easiest to get right on a whiteboard, or on paper. In his experience, it’s been great for getting things ‘out’ quickly, and then only formalising/digitising whatever his team will continue to focus on going forward. It keeps things dynamic, and means there’s a little more space for creating a laundry-list of things to choose from.
Move to development!
At this point, Sizwe’s teams would have discussed and agreed on the following things:
- A clear end-goal
- A bullet-by-bullet list of functions and their endpoints
- A comparison of needs and resources
- Modularised team roles
- Clearly defined edge cases and “code-red” bugs
Now, his teams can move into the development phase and begin building the relevant product or feature. Woot!
A ‘hack’ to make it effective:
In theory, you could plan forever; but project planning is only effective if you can call it and actually move to development.
Sizwe’s teams have got this right by following an MVP approach. Although Sizwe puts a lot of time and effort into scoping things out in detail, his ‘trigger’ for moving on to the next step is agreement amongst the team, and with the business:
“You’re not going to build the perfect product immediately, so just MVP it. You’ve got this feature, now you do this, and then you refine it: How can we better it, what’s wrong with it? And then you keep doing that iterative development. All you need is that universal agreement, and then you just run with it.”
Another big lesson for Sizwe has been to find a rhythm that works for the team. He makes sure that his teams understand each other, develop a rhythm and a pattern that works for them, and a methodology that enables everyone as much as possible.
“The quicker you develop a rhythm,” he explains, “the quicker your project planning will go, and from that the quicker you’ll start coding and developing.”
To try Sizwe’s process out for yourself, download his project scoping template by clicking here or on the image above, print it out, and use it the next time you are planning a product or feature with your team, or even by yourself!
