If you find yourself in the enviable position of working with a software developer to solve a problem or seize an opportunity, you might discover that listening to them is like listening to someone who speaks a different language. It’s kind of true, actually!
We’re here to take the mystery away and help you understand some of the most common terms you’re likely to hear them say. Since agile/scrum is the framework we use, we’ll start with things to help you get the lay of the agile land.
1) Agile
Agile is an approach to software development that emphasizes the frequent delivery of working software, quick response to changing requirements, and close collaboration within the team and with the client. You might not think that’s all that revolutionary unless you understand how most people did development before. That way was called “waterfall.”
Waterfall is pretty much the opposite of agile. With the waterfall approach, developers define ALL the functionality details (i.e., requirements) up front, then design everything, then code everything, then 6 months or 3 years later, you finally get to see the finished product. Not a great way to go if you think anything might change in those 3 years (if you don’t think anything will change, trust us, it will).
The most obvious difference between agile and waterfall is that requirements are fleshed out throughout the entire project instead of all up front. Without getting too far into the weeds here, the agile approach better accommodates inevitable changes in requirements and focuses on delivering value early and often. So, instead of waiting 3 years to see something, you might wait only 3 weeks.
2) Scrum
Scrum is an agile framework used to build software (or anything, really). The scrum process is all about collaboration and delivering the most value as quickly as possible without compromising quality. The scrum team works from a project backlog (see below) of requirements and in short “sprints” (see below again) defines, designs, develops, and tests the subset of functionality deemed to have the highest business value at the time. Then they rinse and repeat until the work is all done or the stakeholder(s) decide(s) enough value has been realized.
3) Sprint
In agile, a sprint is an increment of time during which a given subset of work will be done. Sprints—sometimes called iterations—are anywhere between a week and a month, depending on project needs. At Far Reach, we work in two-week sprints.
4) User Story
In agile, requirements are documented in the form of user stories. While there are different formats, the purpose is the same—to describe a feature from the viewpoint of the user. This helps remind developers that they’re not building the app for themselves.
5) Backlog
A backlog is a prioritized list of user stories. User stories remain in the backlog until the team is ready to work on them.
6) Points
Points are used to estimate the effort it will take to complete a user story. Instead of just estimating in hours, teams estimate in points to account for the complexity and risk associated with a story. Estimates based solely on time, rather than effort, are doomed to be off. Clients don’t like it when estimates are off. And, believe it or not, developers don’t either.
7) Pair programming
Pair programming is pretty much what it sounds like. It’s two developers working together on the same thing at the same time.
You might think, “Why would you pay two people to work on the same exact thing at the same exact time?” At first glance, it may seem like a redundant waste of time and money. The truth is, though, it’s anything but.
Entire books have been written about pair programming, but here’s a quick look at some of the benefits:
- When you have two sets of eyes on something as it’s being coded, many more bugs are discovered much earlier in the development process. And the earlier a bug is found, the less costly it is to fix.
- Learning and knowledge-sharing are greatly enhanced. To be effective at what we do, we have to learn new stuff all the time. Working with another person to solve a problem is one of the best, most efficient ways to learn.
- Productivity and focus increase. It’s easier to ignore distractions when you have another person at your side. The diversion of, “Oh, I’ll just check Facebok or email real quick,” becomes much less appealing.
8) MVP
MVP stands for minimum viable product, which is a core tenant of the Lean Startup methodology popularized by Eric Ries in his book, The Lean Startup. Ries defines an MVP as, “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
So, it’s a functioning product, but more importantly, it’s a learning tool. By starting with the minimal set of features that will attract users, you learn what people value and what they’ll pay for. The ability to learn quickly reduces risk—you’re not playing a guessing game because you have actual data to back it up—and gets paying customers for your product faster.
We also use the MVP concept to help clients manage their budgets. Clients typically have a lot of great ideas about what to include in their products. And we love it when people are passionate about their products and their ideas. Even so, most of the time we encourage an MVP approach where we develop features that meet users’ needs and add value, but that maybe don’t offer ALL the bells and whistles. Then we put these features in front of users, get their feedback, and enhance them from there only if needed. This helps ensure we’re allocating budget to the things users actually value instead of things we think they value.
9) User Experience (UX)
User experience design (UX), at its core, is exactly what you might think—the design of an end-user’s interaction with a product, service, or entity. Since we’re talking about nerd-speak here, though, let’s limit our discussion to users’ interactions with software.
Our friends at Visual Logic Group describe UX as the art of designing products that are useful (solving the right problem the right way), usable (when the software experience blends into the background), and desirable (when customers prefer your product to the competition).
At a high level, it involves research, design, and lots of testing with real users to make sure those three criteria are met. And when done well, it can reduce the cost of the software development effort, ongoing support costs, and—most importantly—risk. All this while increasing customers’ satisfaction with the product.
10) QA Testing
With quality assurance (QA) testing, once again, the name kind of says it all. QA testing is the process of validating the content, flows, functionality, and overall usability of an application before releasing it to users. While some people like to think it’s optional—skipping it to save some budget during development—we don’t recommend it. Remember, fixing bugs found early in the development process saves money.
Often times, developers find their own bugs by testing as they build. The reality is, though, developers are usually too close to the code to thoroughly test what they develop. It’s always smart to have someone else test their code, or to automate the testing where possible, to ensure the functionality performs as expected.
Testing is its own kind of art. Not everybody likes doing it and not everybody is good at it. A good QA tester can save you and your end-users lots and lots of frustration.
Hopefully this list will take some of the mystery out of your next conversation with your development team. If there are any other nerd-speak words or phrases that confuse you,
reach out and we’ll do our best to translate!