Prioritising software development is a very interesting topic for cash-and-time-limited startups, so it’s important to operate a well-driven and reactive development approach.
This is my personal view on how we do things at Glisser. It doesn’t mean it’s the perfect or only way to do things, but it’s a model that tends to work well for us.
“Can you build this?” – don’t just say yes
Whether you are working in a company or as a contractor, the very first question you must ask your product owner (or client) is “what is the fundamental business value behind the request, feature or task?”
Do not commit to building anything until you understand the value behind it.
I know this sounds overly simple but it is too often forgotten.
Not only will it help your product owners to clarify the client requirements, but will also provide your team with a good starting point from which to deliver a product that meets expectations and stays aligned with your own business goals.
You should come out of this exercise with a clear picture of what’s the most important outcome in the eyes of the client and the product owner, with a relative order of importance of everything else.
Get good at feature scoping
You can prioritise well if you have a good idea of what’s needed to complete the task. The next step is to undertake a time and scope analysis of each feature:
How long is this going to take to build?
This is always the second question coming from the product owner, after they’ve asked whether you can build it in the first place. It can be daunting at first, but you shouldn’t feel bad if you miscalculate a little because the purpose here is to give an guideline estimation of the size of the job. The product owner needs to understand feasibility, to price it, to set client expectations, and perhaps determine the need versus other competing client requests
It can take longer or shorter than your estimate – that’s okay (although the latter will please your customer). But broadly you want to convey whether you’re talking about a three-month project, one week job, three days, or 5 minutes?
I tend to overestimate because I like to play it safe, and I know it annoys people, but ultimately we have to deliver on client events which are firmly fixed in time. We can’t miss client deadlines because their 35,000 person event won’t be moved because we underestimated the task.
I always think it’s good to factor in some extra time to perform architecture or code refactoring, or anything that will benefit your platform on the long run.
I mean it’s 2017 now: my advice is to be thoughtful of the next person either extending or maintaining your code, you don’t really want them to deal with a bowl of spaghetti. Your reputation is important internally and for your CV, and products simply can’t afford to be built on shoddy code if they are to be really scalable.
Scope, what’s that?
Generally, it’s the extent of the overall product that your code change will affect. The two questions I ask myself when scoping are:
- Functionality: How much is this feature going to affect my platform?
- Architecturally: What will be the affected components?
Looking at functionality, I then ask, “is it global? Self-contained or small?”
Knowing the footprint of the feature is going to help you come up with better design, implementation and testing. Keep in mind that you should be enforcing a ‘self-contained’ attitude towards building features. The more decoupled they are, the more flexible your system becomes.
Decoupled? Yes, decoupled. If one feature is down on your environment, it should not impact the rest of the system. You want to minimise the impact of your feature on the overall product. This also has an added benefit of using less code to perform more.
Looking at the architecture, I ask, “is this feature a back end only job? Front end? Both? How many endpoints are affected?”
This is important because it will help you organise the work among your team and also help you to organise the release of your features (allowing continuous integration).
(Don’t be afraid to) scope it down
If you’re dealing with a global rather than self-contained feature, don’t be shy about suggesting a reduced scope. Engage with your product owner or client to come up with a refined option. You may be able to meet their primary requirements and their timescales without delivering everything they originally asked for.
Small, well-defined scopes allow quicker delivery with less risk to the product, and are easier to maintain in the long run. You can always readjust your requirements once your feature is deployed based on proper live metrics. Embrace LEAN methodologies.
As I always say,
No need to build a sports car, if your users only want to ride a bike.