Blog

I posted about establishing your Milestones and Sprints in the last section. At this point, you should have a pretty good idea of the scope of the project. For example, is it 4-two week sprints for a total of eight weeks? If you have one developer declare that they can whip it out in a week and someone else say 12 weeks, keep looking to find some middle ground in project scope. If it sounds too good to be true, it likely is!

Contracts

I would highly recommend a Contractor Agreement on this type of project. The typical contract agreement is a two part document: Master Services Agreement (MSA) and a Statement of Work (SOW). They can be generated by either party – I’ve attached a sample version here, Master Agreement w. SOW as a downloadable file. Please note, I’m not an attorney (I’ve only hired a lot of them) and I’m not practicing law.

Also, you don’t want to get into the process of paying a developer and then having them ask for more money while they hold your code hostage. Never pay in advance, unless you want to be parted with your cash.

Master Services Agreement is a single contract for what could be multiple projects, then you will only have to change the SOW for future work. Components of the MSA:

• Outline the parties, contacts, invoicing
• Ownership of work – in a traditional work for hire, the developer doesn’t own the rights to the work, you do as the buyer
• Warranty – e.g. code delivered via GitHub in working order, with no bugs
• Contractor status vs. employee, non-solicitation

Components of the SOW:

• Services
• Schedule
  • Sprints
• Deliverables
• Fees usually corresponding with the completion of the sprints
• Payment Terms

Signature pages exist for both the MSA and the SOW. Make sure they get signed before you proceed. If there is anything that isn’t clear in the SOW, get it clear. If you need to add a second phase or more scope, you can add an updated SOW.

Fuzzy contracts and fuzzy scope documents will produce fuzzy products (that don’t ship) that will create conflict. Get clear on what you’re going to have delivered. Allow adequate time to negotiate the contract.

Get to wireframing

Now you’re going to turn the Specification (Spec) into the screens that you will be using on the web or mobile app. This is only to test the flow and to make sure you have the right fields in the right orders. Download a tool called Skitch by Evernote or Greenshot for Windows. These tools allow you to capture a screenshot, and to use arrows and boxes to visually communicate with your designer/developer.

We use Slack as our communications platform. It’s easy to pull over the image with the visual edits and add the text edits in the Slack application.

• How many screens?
• Page Headings
  • Page Content – what instructions do you need on the page?
• First Time User Experience – 1XUX – does your customer understand what to do on the specific screen?
  • Register
  • Sign in
  • Setup
• Functions
  • Text Boxes
  • Check Boxes
  • Pick Lists
• Buttons
  • Next
  • Back

Locking Down the Wireframes

You’ll need to sign off on the wireframes before the development side of the project starts. Think of this like building a house – you can come back and change something later, but it’s best to nail it down before you go into the dev stage.

Code Review/Bug Fixes

Before the final payout, you’ll need to find someone to do a code review. Let your developer know that you’ll be having a third party do Code Review. That will help them produce better quality code.

Bug tracking and bug fixes need to be an area that you are actively managing with the developer. You can use a tool as simple as Google Sheets or a more complex tool for bug tracking.

Standups

If you’re not with the team, you likely won’t need to do daily standups. But instead, schedule weekly standups to review progress.  Until you have a solid portion of development complete, you likely won’t be able to see much. But you’ll want to make sure the functionality still works in a way with all of the process flows.