Why is scoping so important?

Why is scoping so important?

We love this question!

When we hear this we know that we’re dealing with someone who is asking the right things and wanting to truly understand what it takes to create a great App. There’s a direct connection between curious, open minded and informed clients and successful outcomes. It’s been proven time and time again so if you’ve found your way to this article, you are on the right track!

This may sound like a dumb question but what actually is scoping?

Don’t worry, there is no such thing as a dumb question when you’re doing research and learning about software development! At the highest level, scoping is the process of taking your great idea for an Application and turning it into a detailed action plan for bringing the concept to life.

Think about it this way; if you were building a house you wouldn’t just buy a block of land, hire some equipment and start merrily digging away. Why would you do that? How would you know what to do? It would be madness wouldn’t it? Now, you might end up with some kind of house using this approach but it’s a good bet you will have made a lot of mistakes along the way and your home might be a little, how to put it, wonky. You will have taken far more time and spent far more money than you needed to if you’d just taken the time to plan out your construction before the first spade penetrated the ground.

Talk to any experienced developer and they will inevitably have a story or two about clients who thought they could save some money by skimping on or avoiding scoping completely. The results are almost universally disappointing.

This is why scoping should be considered the single most important part of your development journey.

What can I expect during scoping?

Even in the early stages of the project you very likely have a great idea of the broad functionality (stuff that your App can do) that you want to see in your Application. You might also have a solid understanding of your target user and you might even have done some early stage branding work to give your idea a look and feel. All of this is fantastic and will go a long way towards saving you time when you start working with a team of professional software developers. But here’s the thing, what we and virtually all development companies have experienced is how much things change once you move into the first real stage of software development; the scoping process.

During scoping, you might work with a team that looks something like this;

• a project manager – to take overall control of the journey of building your Application
• a business analyst – to help you understand how the Application might reflect your business model
• a senior developer – to make sure we can achieve what you want using currently available technology
• a UX/UI designer – to make sure your Application provides a wonderful experience and that your users can find what they want quickly

The actual make up of a scope team will vary from company to company but the good ones will cover all of the elements that I outline above. In fact, you should make a point of ensuring whomever you choose to do your work, covers all of these areas. This is best practice and is essential for a successful outcome.

Regardless of what the actual team looks like, you can bet they will have a vast amount of experience taking fantastic concepts and turning them into great products. Invariably they will come up with new ideas and ways you can achieve your goals and make suggestions that you hadn’t thought of after all, that’s their job and they do it day in, day out. During scoping, all ideas will be put on the table for consideration and that’s a positive thing, you definitely want that.

Given what we’ve just looked at I’m sure it won’t come as a great surprise to learn that, once you spend a couple of weeks with these professionals really unpacking your concept, the early stage idea you started with at the beginning of the scoping process will look quite different by the end of it.

In other words, you might have come into it thinking you were building a two story townhouse with a pool but you ended up realising you actually want a bungalow!

What will you need from me during scoping?

As the originator of the idea or the person responsible for making decisions about what does and doesn’t go into the App, you will play a major role during scoping sessions. In fact, you’re the most important person in the team! As the originator of the idea the team will be looking to you as the subject matter expert, in other words the person who really knows what this product is all about, who it’s aimed and why it’s so valuable to them. This role is called the product owner role.

You will either need to act as the product owner (the ultimate decision maker) yourself or nominate somebody to act in that capacity. There will be occasions when you’ll be presented with a number of options for solving a problem and in the end, the decision can only be made by you. Your team will advise as to the pro’s and con’s of each option but you must make the final decision. This is the primary role of the product owner.

How much time can you dedicate to your project weekly? Think about this before you kick off scoping. It’s not unusual for a product owner to be needed for 2 intensive meetings – 2 to 3 hours each – per week either in person or by teleconference plus other ad hoc phone calls as the scope progresses. You should factor this into your thinking as you get closer to kicking off your project.

There’s a couple of important things to mention here. Firstly; as you move through the scoping process your team should be able to make sure you are not getting too crazy and asking for so much functionality that you will blow out your budget. In other words, it’s their job to make sure they keep an eye on how big the project is getting and keep things under control.

Secondly; as you decide what cool stuff you want your App to do, your scope team project manager should be asking you to prioritise all that cool stuff using something along the lines of;

• Must have functionality
• Should have functionality or
• Could have functionality

Why is it so important to prioritise? Because In truth even the best scope teams can’t judge exactly when they have scoped the precise amount of cool stuff to fit neatly into a set budget. But that’s ok, at the end of scoping your developer should still go through the process of estimating the time and cost to build everything that was actually scoped. If the estimate comes in above the available budget don’t panic, together with your scope team you can take functionality out – using the must have, could have and should have priority categories – until the cost matches the funds. And remember, when we talk about ‘functionality’ we really just mean stuff that your App can do.

Epics and User Stories

I remember the first time I heard these terms, my first thought was what on earth does that mean! They are kind of esoteric but actually describe something extremely important.

As you progress through your scoping, you will start to identify the major functional (cool stuff as well as boring stuff) things that you want to see in your App. Epics are just a way of putting a descriptor on each chunk of functionality. An example of an epic could be ‘user login’ or ‘password reset’, ‘user profile’ or ‘notifications’.

Now, if you’re thinking that each one of those Epics would have a bunch of other functions associated with them you’d be totally correct. Every single thing that’s involved in each Epic must be described so that the developer knows what to build. ‘Notifications’ is a good example of this, ‘notifications’ could cover a whole range of different things and could apply to many different parts of the Application. We need to detail each one individually and these detailed descriptions are called User Stories. Each Epic will have a number of User Stories associated with it.

What can I expect to see at the end of scoping?

The deliverables that will be handed over at the end of scoping will inevitably vary from company to company but here’s some common deliverables you should expect to see;

• User flow diagrams – in other words a map of how each type of user who interacts with your App will move through its functions
• Wireframes – think of the wireframe as a building plan which lays out the basic structure of the App and shows you how your App will look. They can either be quite simple (lo-fi) of more detailed (hi-fi)
• Prototype – similar to a wireframe but prototypes are often interactive and can look like the finished product without any genuine functionality. This means you can click on menu items and buttons and it looks and feels like a real App. A great way to test the user flow.
• Backlog – this is a collection of all the Epics and User Stories you worked on.

the backlog is built up gradually over the course of the scoping process and is essentially a list describing every function that the App will perform as well as all the work items that will be needed to make it operate as intended.

• Estimations – based on all the Epics and User Stories in the backlog your scope team will be able to deliver an estimate of how long it might take to build the Application. Remember though, this is only an estimate!
• A scope plan – the scope plan should encompass everything listed here as well as detailing how the development team will look to tackle the project. This could include a break down of agreed milestones and staged releases.

What else should I be aware of before I start scoping?

There’s one last thing that’s worth knowing before you start. You don’t need to make any decisions on this until the end of scoping but there’s no harm in you knowing what your options are in case they aren’t made clear to you. Which they should be.

I’m talking about how you might want to budget for the building phase of your development. This is the phase that comes immediately after you’ve done the scoping work and is when the developers start writing the code that will bring your App to life.

There are fundamentally 3 different ways of thinking when it comes to estimating the actual final cost of building your application and you need to be aware of this before you enter into an agreement with a development company.

1. Fixed cost flexible scope
2. Fixed scope flexible cost
3. Fixed scope fixed cost

1. Fixed cost variable scope

In this approach, you fix the number of weeks that the team spends writing code and building your App. Your developer should be able to give you a weekly rate so by fixing the time, you fix the cost. Remember, because the time estimations you get at the end of scope are not precise, you need to be flexible on the number of User Stories you actually get developed. It’s highly unlikely that all the functionality you unpacked during scoping will make it into the final built application and this can be troublesome if you really want to see all those features in there.

2. Fixed scope variable cost

What if you get to the end of scoping and you absolutely must have every feature built and included in your App? The answer is you fix the scope! This way the developers keep writing code until every User Story you scoped has been completed. But again, because the time estimations are just that, estimations, there’s no way of knowing for sure exactly how many weeks will be needed to do all the work. Therefore, you need to be flexible on the budget since the number of required weeks is unknown. The problem with this approach is that you have no way of knowing how much you’re going to actually end up spending on your app and you need to place a huge amount of trust in your developers.

3. Fixed scope fixed cost

This approach has some major benefits most important of which is giving you certainty over how much you’ll be spending and crucially, what functionality you’ll have in your app at the end of the build. In this approach your developer will give you a fixed price for developing everything that was scoped or all the functionality you want in your app whichever applies. If you can find a supplier that will offer this it is well worth considering but a lot of companies will shy away from this especially if they are not very confident in their estimations process.

What can I do to prepare for my first scoping meeting?

Any work you can do before you start paying your scoping team will of course save you money which you can use for something else. Maybe more scoping time or more functionality built? Here’s a few suggestions for how you might prepare for that first meeting;

• Articulate and document the key problem that you want to solve for your target user with your App – an MVP approach requires focus on solving one core user problem and nailing that to prove value, whilst creating a roadmap for future releases.
• Document the key functions that you’d like to see in your App
• Consider and document the business model for the App – how will the App reflect any existing business processes?
• Consider how you will monetise the App
• Consider and document the different user groups that will interact with the App
• Consider and be ready to discuss your preferred technology stack if you have a preference
• Consider and be ready to discuss what devices you need the App to be available on for example laptop, tablet, mobile, all or a mix of them.
• Articulate any specific wishes with regards to user flows – create lo-fi wireframes if you’re able or if not drawings can be helpful. Neither is essential.
• Consider and document the overall user experience you’d like to see in the App, the look and feel you’re hoping for.

I truly hope this article has helped you to understand why scoping is the most important part of the process of building an Application. It doesn’t matter if you’re building something totally new and bespoke from scratch or if you’re adding more functionality to an existing App, don’t try and save money or cut corners here. Underscoping causes real and usually expensive problems once the software developers start to write code and you will end up spending more far than you needed to and risk ending up with a disappointing result.

Good luck with your project!