Acceptance criteria (AC) are the pre-established standards that a project must meet to satisfy its users. The AC should define the end goals; furthermore, it defines when the project is done. This is important so that nothing is forgotten in the process and there is no ambiguity in the design.
The AC should be established before development begins. At this point, the AC will be written focusing on the end goals. If the AC is written after development begins, it is likely that you will write the criteria based off how your program currently functions.
The AC should define what you want the program to do. The criteria should only focus on the "what" not the "how", so implementation does not need to be included.
Each part of the AC should be written as a pass/fail statement that can easily be translated into at least one test case. Each statement should be a clear, concise goal. The goals should be written in simple terms; anyone reading them should be able to understand what you want.
One format for writing criteria is given/when/then statements. Given a certain condition, when I perform this action, then this should occur. The given conditions ("given") can include who the user is or what functions they have already performed (e.g. the user selected three emails). The action performed ("when") could be clicking a button (e.g. when the user clicks a sort button). What occurs ("then") should be the result of the action (ex. emails get sorted by date).
You have created your AC - now what? The AC can be used to generate test cases for your program. Writing each statement in the AC as pass/fail makes this transition to testing easier. Refer back to the AC often and ensure it stays updated. As you come up with more ideas for functions, add them to the AC. Your AC will eventually tell you when you have accomplished everything you wanted, which means you are done!
According to Eric Reids, the Minimum Viable Product (MVP) is defined 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".
What does that definition really mean? The MVP is a version of the product with the least amount of functionality possible. Every project has a different MVP; some may just be a landing page, while others may be a working prototype. This explains the "least effort" aspect of the definition.
The users of the MVP will provide feedback, which is important to take into consideration. This is where the "maximum amount of validated learning" comes into play. Validated learning is trying a new idea on customers to "validate" the effect.
The main purposes of an MVP are to gain information from the user and to conserve resources. The user feedback will tell you where to spend the most time making changes. Time is the most precious of your resources. It is not worth it to spend hours working on a functionality that users of the MVP will say to remove. Thus, you should start with the least functionality then build up from there. This is significantly less risky than releasing a finished product with no feedback.
After receiving responses, you must make changes to the product. These improvements can be small or large. Don't be afraid to drastically change the product if that is what the feedback suggests. Unfortunately, you may even find that the market simply is not interested in your product. So sometimes completely scrapping the idea is the solution.
Project management is a key part of undertaking any tech project. It helps you learn from your mistakes and make progress in the future. Even in the context of a personal project, which might have a team as small as 1-4 people, keeping these principles in mind can be helpful to improve both the quality of your work and the enjoyment of your workflow.
In this section, we'll discuss a few aspects of project management, all of which tie into Agile. Agile is a highly effective method of developing software from which every team and individual can learn.
Agile methodologies are a style of software project management that emphasizes flexibility, prioritizing people over processes, and, most importantly, iterative development.
Agile works for software development in particular because of how project specifications can change at a moment's notice, how quickly the technological landscape changes, and how many moving parts there tend to be in every large software project. In fact, it's been proven to increase efficiency and productivity!
Work is divided into cycles called "sprints" where every member of the team has certain user stories (essentially tasks) to complete in that sprint. At the end of each sprint, the team re-evaluates and decides what stories to tackle next, taking in account customer feedback and changing needs of the project.
This style of work is designed for teams of 5-10 people, but can be implemented with any team or even solo! It's all about the dedication to continuous improvement and willingness to be flexible.
A key principle of Agile is kaizen, which is a Japanese word that means "continuous improvement". It's a philosophy that is a part of iterative development -- all about focusing on activities that add value and not wasting precious resources on activities that do not.
There are a number of productivity tools designed with Agile development in mind. Some of the most popular are JIRA, Trello, and Monday. They all include the feature of boards where user stories are staged, rather than a typical to-do list. This allows you get a birds-eye view of the project and assign different tasks to different people appropriately. We use Trello for keeping track of HackBU tasks, and it's helped us stay on track!
Cost estimation is the skill of managing your budget. This "budget" refers to a number of things - your financial budget of course, but you can view other resources like time, people, and skills as resources as a budget you need to keep track of as well. Estimating how costly an endeavor will be allows you to plan and, when working with others, delegate appropriately.
In Agile, costs should not be considered a separate task that's completed once and then filed away. Instead, it's an integrative process involving every member of the team (including the tech and business sides) that continues to occur as more specifications are added to the product and more roadblocks come in your way. Estimating costs iteratively allows you to take in account new risk and opportunity as they arise, creating a more successful product.
Establishing a time frame is important to planning a personal project. As busy college students, it can be challenging to balance working consistently on a personal project with the demands of classes, work, and clubs, so establishing a time frame helps you deliver on your plans.
A tactic Agile uses to be as accurate as possible in figuring out timeframe is assigning story points (a way to keep track of team velocity) based on complexity, not time. For example, compiling a program could take as long as a day, but if it's an easy task for the engineer, it's a low-complexity task. Prioritizing complexity makes the story points a much more useful way to analyze productivity.
When you're thinking about what you can accomplish in any given sprint, analyze your past velocity and keep track of the kinds of things that slow you down. A way you can do this is by using a burndown chart to keep track of how many story points are being completed. This is also a great way to start thinking about kaizen.
If Agile is something that interests you, there are a lot of resources online where you can learn more about Agile development!
Info about Scrum (an Agile framework).
More in-depth reading (this includes some important concepts such as daily stand-ups and definition of done).