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.


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.


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.”


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.


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.


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.

Leave a Reply

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