General Software Development Jargons Hat
Agile
This is a way of building software that helps teams ship out small, useful pieces of the product regularly, so they don’t sit on a huge final release for ages.
Your team is fixing a shopping app. Instead of dreaming up every little thing you’ll finish over a whole year, you send out little features every few weeks. One sprint you finish “wishlist,” the next you finish “dark mode.”
When you’ll think about it: At the very start of a project, when you decide how the team will work together all the way through.
Scrum
This is one style of Agile. In Scrum, you work in short, set time blocks called sprints, hold regular meetings, and everyone knows their part.
For example, You kick off the week every Monday ( Day could be any day - weekdays ) with Sprint Planning, then have a 15-minute check-in every day ( Daily Stand up ) , and wrap up every two weeks with a demo for the folks who care.
When this can happen ? Every day during the stand-ups, when you’re deciding what goes in the next sprint, and then when you’re looking back on what went well at the retrospective.
Sprint
The sprint is that short work block—normally 1 to 4 weeks long—when the team zeroes in on finishing a set of tasks.
Example: It’s week 2 of a 2-week sprint and you’re about to lock down the “Add to Cart” feature for the app before the deadline bell rings on Friday.
When you’re mapping out what the team can get done in the next chunk of time.
Backlog
Think of this as a big bucket where we toss every cool idea, bug fix, or little change we might want to do later but not right this second.
The PM thinks a “Voice Search” feature would be awesome, so she drops it in the backlog today for maybe next month or the month after.
When ? We pull it out during backlog refinement to see if it should go to the front of the line.
User Story
This is a quick peek at a feature from the user’s side of the screen. Like, “As a shopper, I want to see shoes sorted by price so I can grab my size without scrolling for ages.”
A ticket in JIRA( Software Tool) reads, “As a customer, I want to sort gifts by brand so I can pick the right one fast.”
When ? We revisit it during sprint planning, refine the backlog, and test it in QA.
Epic
This is a big mountain of work, too big to climb in one sprint. We chop it into smaller, bite-sized user stories we can tackle sprint by sprint, so it feels less scary. In tech language , a big chunk of work in our backlog that can’t be done in one sprint because it’s too huge or complex, so we chop it into smaller stories.
The “Rewards Program” epic will include smaller bits like “Sign-up Flow,” “Points Calculation,” and “Rewards Redemption.”
When to use: Anytime we want to group stories that are all trying to hit the same big goal.
Acceptance Criteria
There should be a clear list of must-haves that let us know when a story or job is finished and ready to be used.
For example, the criteria for the "Reset Password" story could be: - The user gets an email with a new password within two minutes.
- The reset link will no longer work in 24 hours.
When: Before we start writing code, while QA tests, and again during the sprint review.
MVP stands for "Minimum Viable Product."
The most basic form of a product that real people can use and let us know what they think.
For the first MVP, there is only a hotel search and booking feature. There are no reviews, maps, or flights on this page.
When to make a choice: Pick the smallest form of the product that we can still use and that will still give us good feedback.
Iterations
One full cycle in which the team plans, builds, tests, and sends out a piece of work. After that, they look at what they did and make it better.
In the first version, the "Checkout" page could only accept credit cards. PayPal and Apple Pay will be added in the next version, giving users more ways to pay.
When this happen ? You’ll hear it in sprint reviews, when we write release notes, and when we figure out what to improve next.
Waterfall Model
This is an older method. You finish each step—planning, coding, testing, and releasing—one right after the other, and you don’t circle back.
A government project lists all the requirements at the start, then creates the design, builds the code, and runs tests in order over a year and a half, without changing anything from the planning phase.
When do we use ? People usually bring it up to show why making changes in the middle of a project can be tricky, especially when you’re comparing it to Agile.
