Don’t Swallow Your Plate of Food Whole (as applied to Software Projects)

Software projects can be big and unwieldy, don’t eat them whole!

If you don’t have much experience running software projects, it might not be obvious how to break up the work. Even if you do have a lot of experience, sometimes you can get into a rut.

In a software project there are typically a lot of different components that need to be done, server stuff, backend, frontend, and other supporting areas. Some things depend on other things to be done first, and need to go in the right order. Some pieces are crucial (‘a payments system’) and other pieces are not (‘add gradients to the buttons’) but you might still want both to be done.

You need some way to break the project up into pieces, and communicate that to your team.

User Stories

It might sound strange to a newcomer to software projects, but a single piece of a software project is called a “User Story”. A user story (or just “story”) can be defined as the smallest unit of work in software development. Or more specifically in user-centric software development.

A story needs to be something that helps a user. So it needs to be an end-to-end piece of the system, that performs a useful function, even something very mundane.

The general rule is if it can be broken down any further than it already is, then it’s not broken down enough. If you break it into stories, then you can very easily prioritize the stories into high, medium, and low priorities, which will help your organization (or party of 1) save time and money getting to the goal: a completed project, or at least the first phase!

Can I Just Have A Giant Blob Rather Than Stories?

The quick answer is do you want to eat a giant blob? (just kidding)

I get it, you have a giant blob and it can’t be broken up. So it’s a good user story right? It’s going to cost you a million dollars to get it built. But you can’t break it up any further?

“No really, it’s too complicated and if we break it up, we’ll break it.”

I get it but rather than spending time and brain cells on defending your way of doing it, why not spend some of that energy on trying to break the blob into smaller pieces. I think you will be happy you did.

First Things First

First things first means do the important and foundational things first. If you are building a web platform then of course first things are going to include the framework around the platform, the foundational libraries you will need (not to support all future functionality of course, just the libraries that support your initial framework).

But it’t not just about doing the things that later functionality depends on. It’s also about figuring out what’s crucial and what isn’t.

I’ve heard people freak out a little when I ask them what functionality is highest priority (or ‘must-have’) and what is lower (or ‘nice-to-have’). They freak because they think it’s all equally important. The same attitude usually also is accompanied by a fixed budget and wanting to slide everything into the short timeframe. The problem with this attitude is you as the agency or development team may or may not be able to get everything in under the timeline and budget, just like you don’t walk into car dealerships, tell them you want the 8 series BMW, and you want it now, and you want it for your budget of $10,000. By the same token, you don’t get everything you want in software projects all the time just because you want it, under your budget. So when you come to the end of your money, you want to make sure you got the important stuff done.

Larger companies generally understand this concept, but not always. And this leads to getting the features you want, but with unacceptable bugs and cost cutting measures you can’t always see.

So, prioritize everything once you break it down into stories. You will get a better product in the end!

How?

So how do you break up the work? I think it’s easiest to use a tool, but you can use excel, or word, or a piece of paper. You just need to communicate it to your team when you organize it.

I prefer software tools (like softyPM) because you have it saved for posterity. Your excel document might get lost or destroyed. Your piece of paper too 🙂

So for the organization of things, create a project for each software project, or smaller pieces of the project (industry term is ‘Epics’). Either way, you can separate things into larger pieces first if it helps.

It’s important though, if you can try not to have backend pieces separate from frontend pieces, that’s best. What I mean is, if you have a story for a submit button, but it doesn’t do anything, it really shouldn’t be a story. So make the story about submitting the entered data, and include the backend reception of the POSTed data.

So don’t separate backend and frontend, make sure the pieces include both since neither works without the other (unless you are building just an API or something like that, but you still would have API endpoints to create).

So that’s all, hopefully you find this helpful. I read ALL comments, and I might even respond, so go ahead and comment if you liked this post or if you have any questions!

Leave a Reply

Your email address will not be published. Required fields are marked *