Steps to building and updating software
Step 1: Communicate & ask questions
Documentation - Start by creating a readme and getting any documentation links available. Add anything you learn to the documentation as you go.
Question the product & its features - Get as much info as possible about how the software is used, and what it does for their company. Go through the site to get a better understanding. Ask how the end user interacts with the software. After learning how the app works, you'll figure out how it should work and what needs to be done.
Any assumptions you make about what the client wants should be available on a card, in Trello, for their review. Create acceptance tests so that you know what should be happening. Get the client to list and explain every feature they want, and bug they're dealing with. You should know every single feature and change before ever starting to code. This way you can create the appropriate cards in Trello.
Step 2: Trello
Create Trello board - Create a Trello board for the project, with headings for each card column. The following items should have their own columns, in order: Icebox, Features, Bugs, In Review, For Review, Deployed.
New Features - Get the user stories right before you get started. These should explain what types of users use the product, and why they need each feature from their perspective. Your goal is to provide benefit to the client for each feature, by explaining to them what the feature allows. By thoroughly understanding the user stories, it will simplify feature descriptions, and you'll understand what needs to happen to add those features. Put the user story in the in the card, and once the client answers your questions, then you can write the acceptance tests for that user story.
Create acceptance tests - Create cards in Trello that walk the client through the actions their users would take in using the features. Make the acceptance test the title of the card, with the hourly estimate. Refer to these rules when writing acceptance tests, before posting them into Trello. Time estimates should be added to the end of every card title.
Create checklists - Create a checklist for each card. Checklists should spell out each thing that needs to happen to consider that card finished, and that feature/bug fixed.
Bugs - Put the problem in the title of the card along with the time estimate. In the description, include the user story so that it's clear how the feature should work.
Estimate - Go through each bug/feature, and estimate how many hours are required to complete them. Do NOT do this until all features are specked out, or your estimates will be wrong. If you're updating software, estimate how long it will take to fix the bugs, before moving on to estimate the features. The client can then go over the features and prioritize which ones need to happen first. Keep estimates simple. When all the questions on the cards have been answered, and you've set an estimate for each card, the client will move them to the 'Ready' column.
Organize Cards - There should be a card created in Trello for all user stories, features, and bugs. If one card is related to another, assign them with the same label. This will help you later when you have to prioritize the order in which features and bugs get fixed. It's important that you create checklists in each card to outline the process. This will help you make estimates, and will help the client understand what's involved in each change.
Make sure you have a card for each bug & feature, all the information in each card, an hourly estimate, prioritization, and checklists to complete for each.
If you still have questions, post them in each card so that the client can answer them. EVERYTHING, including screenshots of bugs, should be in the cards on the Trello board. This way, you won't be relying on client communication after you start developing. Don't move any cards into the 'Ready' column - the client will do this when they feel you understand 100% of what needs to happen. You shouldn't have any more questions about the cards once you get started.
Step 3: Implementation
Timeline - Before you start, let the client choose the order of the cards. It's up to them to tell you which bugs & features will be worked on first, next, and so on. Explain to the client clearly what's on the agenda for each week.
Card Review - The client will go through the cards, review changes, and make comments. The goal, after specking out all features and bugs, is to work through checklists, and get as many cards into the 'Ready' column as possible before you begin. Work on the cards from the top of the list down, because these are the high-priority cards. By the end, there should be lots of cards in this column, but none of them should have any work started on them yet.
Fixing Bugs - If writing a new test is faster than fixing an old one, then write a new test. If it's something you can fix in several hours, try to do so. When fixing individual bugs, create a branch off of the master for each test, so that no one is waiting for you to finish. Not branching off other branches also saves time should anything need to be fixed or updated. Avoid merging other branches into your current branch.
Be specific - Be specific when asking the client to review a fix or feature you've pushed. If it's still a work in progress, don't ask them to review it yet. If you want them to look at something, keep your questions straightforward. Use card names/columns when you have questions - Don't ask them to simply look at what you're working on.
Troubleshooting - As new problems arise, note them in Trello on the appropriate card. Keep a watch on the cards just in case the client does the same. If it's a problem you can fix efficiently, do it. Economize your time and if you realize upfront that it doesn't make sense to spend time on it, don't. Always check with the client before pushing a fix. This way, you can prevent any interruptions if something breaks elsewhere.
Review - Keep your cards up to date with your estimations. If any items are added to the checklist, make sure to review the estimation and adjust it accordingly. Be sure to notify the client in Slack when you change estimations and checklists.
Step 4: Testing
Testing - Knowing when to test is as important as the testing itself. Find out when is best before you deploy new features and fixes. Create a checklist on a Trello card that lists all tests. Everything needs to work as advertised. Never delete Trello cards. Archive them when they need to go.
Any new issues that pop up during testing should be addressed right then. If fixing one thing causes the other to break, step back. Write out the scenario and think about it before re-addressing the problem.
Step 4: Review
FAQ: Create an FAQ sheet to explain everything the client needs to know that isn't obvious. This way, the client has the information and doesn't need to reach out about how things work.
Review: Simplify as much as possible. Polish features so that they're as easy to use as possible.
Retrospectives - Go over each step in the process and analyze how the project went for you. Examine what went well, and what didn't, so you know how to expedite things in the future.
Have a question that isn't answered by this page? Email firstname.lastname@example.org.