New to Software Projects? Terms You Need to Know

If you are new to software development, either because you have a project to manage, or you are starting out as a developer, you may not know the terms of a software project. So this post will help you be in the know 🙂

My goal isn’t to weigh in on whether something is important, but just to make sure you know what the terms are. Talking about the merits of different approaches is for another blog post.

Agile

What is it: Agile means nimble, quick, highly maneuverable, and in software development, that sort of covers it. Agile (you can read up on wikipedia if you want) has been around for a long time, but really gained traction in the last 20 years or so. There is a whole manifesto describing the method, and the gist of it is that the point of software development is releasing solid code, that performs something useful for users. Further, a team is greater than the sum of it’s members.

Teams also are self-organizing, where possible. This means a team needs to be made up of cross-functional members who can pick up tasks in different categories, such as development, testing, and user research.

In practice: to use agile is to take a software project and break it into smaller pieces, releasing finished code, and iterating as you receive feedback, either internal or external. Also, as much as possible the team should rely on the members to solve problems, not caring who comes up with solutions. The point is that sometimes solutions come from unlikely places, and the important thing is to have a good solution.

Story

What is it: A story, or user story, is the smallest unit of work in software development. A story should be concise, not bloated with requirements, and be a self-contained feature that helps the user.

In Practice: A story is written in the format of “As a (type of) User, I need (feature), so that (reason I need feature).” For example with softyPM, “As a client user, I need team chats stored in the story, so that I can see all notes at any time.”

User

What is it: A User is the person or entity for which the feature is being created. The user might be the end user, but it can also refer to the company, the system, a department, or an internal user.

In practice: Usually when you are writing a story it’s pretty clear who the user is. If the story is about storing a team chat, the user is the one who benefits, or the client. But if you are installing a framework that the end user won’t know about, then you could be installing it for the benefit of the company. So that would be the user.

Persona

What is it: while users are the immediate beneficiaries of a story, personas are user types who you will market the product to. So for example, while ‘the back office system’ might benefit from a story getting done, it won’t be buying your product 🙂 So the backoffice can’t be a persona.

In practice: typically the product manager will create personas to match different user groups who will be targeted as users of the product. A persona includes details such as age group, possibly other demographics if that applies, job titles that would be typical, and a writeup of why they want your product and how it will help them. You can even add a photo of what the user might look like, along with a fictitious name, to make it more concrete.

Epic

What is it: ‘epic’ refers to a category under which you could group stories. Typically this is a major feature or a major part of the application.

In Practice: When writing stories, ask yourself if this fits into an epic that already exists. If there are no epics, ask yourself what feature this would go into. If the story is the feature and there is nothing higher level, then you probably don’t need epics.

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!

The #KEY To Successful Software Projects

This blog post assumes you have a contract or agreement to get software built. Or, maybe you are in a company and you are tasked with getting software built. Either way, I’m going to share what I think is the most crucial element in your success.

If you don’t have a project in front of you or you are trying to pick a vendor, then this still applies, though a little less.

So what is the #key?

The key to successful software projects is and will always be COMMUNICATION.

Nothing derails a project like poor or little communication. That’s why before I will agree to terms, I need to get on the phone with the person on the other side of the project. If they aren’t willing to talk, then I will decline the project.

I haven’t had too many projects go sideways, but one of them was a lady who initially wasn’t willing to jump on a call with me. I should have run the other way but I didn’t, and it led to us having a bad working relationship, and again, she wouldn’t get on a phone call to resolve anything, so I had to end the contract.

So what exactly do we mean by communication in software projects?

Communication leads to an understanding of the work that needs to be done, who needs to do what, and what is most important.

Understanding the work to be done

Understanding of the work to be done entails explaining and being willing to explain again. Some people, after they explain something, aren’t willing to say it again in a different way. As if everyone is or should be just like them. But people are different. People see things differently. And people learn differently. So be willing to explain again, and again, if needed. Also, and this is very crucial, just because you understand something doesn’t mean everyone else does too. So after discussing something, recognize that the other party may have walked away without knowing what they need, so they will be back for more explanation later. This is fine and hey, we’re all just human right? 🙂

Understanding also entails give and take. Software projects are always morphing, as they typically should. If you come up with a design and sit on it for 2 years, the business and competitive landscape is going to change, among other things. That means the original design needs to change. By the same token, projects might change over 6 months, or even a month. This flexibility requires give and take, an understanding that things are defined today but can easily change tomorrow. Both parties need to recognize and allow for this.

Who needs to do what

In software projects it’s important that everyone knows what part of the work falls to them.

In a client / freelancer situation, typically the freelancer owns all the development work, but some clients are also developers and they will be performing some of the work.

What is most important

I cringe when I hear that everything is the same priority, because it’s never true.

Either from the client’s perspective there are ‘must haves’ and ‘nice to haves’, or from a developer perspective, some things are foundational and must be done before other things.

Two ways to evaluate priorities are MVP and SLC.

  • MVP: Minimum Viable Product – this is figuring out what are essential elements to your first release. Typically this accompanies a lean software development approach. In this philosophy, the most important things are the essentials, and the rest of the work is not essential. And from there you can further prioritize what you want done first.
  • SLC: Simple, Lovable and Complete – from Taylor Otwell of Laravel, this encompasses the elements that are needed for V1 of your product, but requires the first version to be simple (in line with the lean approach above), lovable (this includes styling, user experience, and actual usefulness), and complete (which means it accomplishes something useful from end to end.

Getting to the priorities is essential to a fast moving and successful project.

Summary

Without communication, any software project is going to fail.

#abl = The #1 Rule Of Successful Freelancing

#abl or Always Be Learning

I think the most important thing when it comes to making money as a freelancer, is always be learning.

I might not have all the skills I want to have, but by continuously learning I can grow and do things I previously couldn’t do. (sorry if that seems kind of obvious but I think it needs to be said)

I’ve been freelancing since around 2005, when I started my first website. I knew very little but I didn’t wait long to try to make a living from what little I knew!

The website was fun-colorado-family-hikes.com (terrible domain right?) which grew into funcoloradohikes.com which we sold in 2013 or so.

I tried to go fulltime with that gig but it didn’t work out right away, so I got a job. I never gave up the dream of a fulltime from-home gig, so almost as soon as I got home from work, I’d be on the laptop. Weekends, on the laptop. Vacations, laptop.

While my coworkers were doing fantasy football, I spent all my time learning.

Eventually I started a web design company called 6webdesign (closed in 2015) and I picked up a few website redesigns a year. To do that successfully I had to learn HTML, CSS, and a little PHP … truly just enough to be dangerous.

In 2014 I joined a startup and we needed to build V1 of the platform, so it fell to me. I decided on PHP since at least I had some foundation there, but I didn’t know much. So I turned to Codecademy. The free PHP course was great for beginners, and I took the course probably 5 times while I was also building the platform. The overall experience was a lot of fun, but the business never got any funding, so I dropped it in 2015. 2015 was also pretty much the end of my freelancing for a while, since I joined a company where I could work from home, but it was a high level job and required my full attention. 2018 rolled around and I left my job, and started my own company.

I decided to build apps so I needed to learn more! Again Codecademy saved the day.

Now, it’s 2019, and I’ve become expert in Laravel and softyPM is my first React.js application. I wanted to learn React because I like the incredible speed of actions on the page. Even if these aren’t highly complex applications with realtime quotes or games or something like that, users appreciate quick response times in the UI. How did I learn React? I started with … you guessed it … Codecademy.

So the message here is, keep learning, and learn enough to be dangerous, and start building!

I think the key is always build stuff before you are ready!

Thanks for reading! I read EVERY comment, so leave one below and I’ll get back to you. And I’d love to hear your thoughts.