In order to prepare an estimate, our expert teams need proper documentation. If you have experience creating project documentation, it should be quite straightforward. If not, here is a sample ‘Project Overview’ breakdown that outlines business objectives, goals, user stories, page layout and admin features. You can follow the following example to create documentation for your own project. If you need help preparing documentation, please feel free to reach out to hello@buildateam.io with questions.

Project Title:

Company URL:

Business Objective:  (Why are you working on this project? What problem are you trying to solve?)

User Personas: Who is going to use. I.e: moms that don’t work, students that need books etc..

User Stories:  As a customer, I would like to be able to see all available locations to have a cheeseburger around me. As an admin user, I would like to be able to control what locations are visible to the users.

Any research documents or inspirational links:

Monetization Strategy:

Competitor Links:

Interface Inspiration:

Wireframes link :

Technologies / APIs to Use:

Main Sections of the Product and Requirements:

After the project documentation is ready and everyone is agreed on whats being built or accomplished, we can move on to estimating the effort required to deliver a solution.

• In order to provide an estimate we first discuss the project with the product owner to understand the objectives, scope, budget, timeline and preferences
• Depending on how detailed the provided documentation is we might request to start with an investigation / research to complete the missing parts of the requirements
• Depending on the budget and timeline we break tasks into sprints and decide on how big the team / teams should be
• Estimates for projects and tasks are given by either the expert assigned to the project or the team lead through project managers or Account Managers / Business Analysts
• The main goal of an estimate is to provide a solution to the business requirement that includes a breakdown with actionable tasks and hourly estimates
• Whenever reasonable, multiple estimates can be provided for the same project using different frameworks or approaches
• Estimates are best guesses given based on the available information. The more information is provided, the more accurate the estimates can be
• Estimates can include a pessimistic and optimistic columns, when the requirements are very ambiguous or have risks
• There can be different types of estimates:
  • ‘Enterprise-level’ projects require a lot of attention to detail and working out all possible scenarios, integration of many 3rd party APIs, TDD (Test Driven Development) and support of all popular and not very much browsers and platforms. Usually there is a robust, scalable infrastructure supporting the application, that includes monitoring, logging and disaster recovery. Solutions are 99.9% bullet-proof before deployment to production. Higher budgets are expected to cover the time required to work all these steps through with experts
  • ‘Regular’ projects also require attention to detail and include compatibility with most popular browsers. There are usually less interactive and non-crucial features and no TDD included. These things cut out ~40% of time from the Enterprise-level estimates
  • ‘Startup’ projects or MVPs (Minimum Viable Product) usually include the minimum set of features required to launch the feature or website / app. Things are done with great attention, but limited functionality is shipped or open source or ready solutions are used to cut costs down in immediate run. Distinctive elements of the approach: only crucial functionality is shipped, less testing of all possible scenarios is done leaving the feedback and bug reports to the ‘beta users’ or ‘early adopters’
• If the project includes both creative design and development phases, first the estimate will be given for the design phase. Development estimate would most likely change after the designs are delivered
• Ideal documentation for the development phase includes hand-drawn sketches, wireframes with style guides or ready designs accompanied with comments and user stories
• In addition to the breakdown of tasks,  estimates may also include:
  • + 15 % quality assurance time
  • + 10 % bug fixing time
  • + 20 % project management and communication time
  • so 10 hrs of dev time might also include + 1.5 hrs QA + 1 hr bug fixing + 2 hrs PM = 14.5 hrs
• Like mostly with everything in this world the general rule is ‘Good. Cheap. Fast. But You Can Only Pick Two.’ Please be reasonable when trying to cut the time estimates. Certain things just take time. We can definitely cut corners to save some budget now, but it would most certainly become a so called ‘technical debt’ that will just make things difficult in the future
• We follow agile methodology and work only with experts. Usually the factual time tracked for the project or task is less than estimated, but there are also cases when work takes more time due to unexpected conflicts, bugs, issues in open-source frameworks that are being used etc. It is possible the time spent would be different for ~ +/- 20% from the original estimates
• If the tasks take more time we make our best effort to inform the product owner about it upfront
• Depending on the business objectives estimates can include:
  • Business Analysis
  • Wireframes and Design
  • Setup of Environments
  • Development
  • QA
  • Digital Marketing

Project teams consist of members with complementing skills that take care of tasks that they are experts in. Below are common project roles, responsibilities and tools used. When submitting new tasks, consider which specialists would be required to tackle the task. While some of the roles occasionally get combined by the same person on larger projects everyone has things to take care of.

• Product Owners:
  • Have a vision and convey that vision to the team.
• Business Analysts:
  • Offer top-level technical solutions to business problems and objectives
• Project Managers:
  • Manage delivery of multiple projects from receiving the requirements to successful release
• UX/UI Designers:
  • Are primarily concerned with how the product feels and how the product is laid out
• Digital Marketers:
  • Develop a strategy used in marketing a company’s product online
• Team Leads:
  • Manages and leads a team of experts
• Database Administrators:
  • Design and optimize performance, integrity and security of databases
• Backend Developers:
  • Build and maintain server-side of an application, which includes the server-side of the application, and the database
• Frontend Developers:
  • Build the frontend, or client-side of an application
• DevOps Engineers:
  • Build and maintain tools for deployment, monitoring and operations. Troubleshoot and resolve hosting related issues on development, staging and production environments.
• QA Engineers:
  • Design and implement manual or automation tests that help debug the application

Adding and Editing Project Members

In order to add/remove or edit member roles, click on the ‘Members’ tab under the project view. 

The work process for Support engineer

Each project has a Google Drive folder associated with it.shared with the team. Files are shared with the whole team. Please create a free Gmail account if you don’t have one.

The folder structure is:

• {Company Name} {Project Name} (folder) /
  • {Project Name} Overview (folder)
    • {Project Name} Overview (Google document)
    • Associated project files
  • {Project Name} Calls (folder)
    • Call recordings
  • {Project Name} Estimates (folder)
    • {Project Name} Estimate (Google spreadsheet)
  • {Project Name} Design(folder)
    • Design Assets ( source files for designs )
  • {Project Name} Timesheets (folder)
    • {Project Name} Timesheets (Google spreadsheet)
  • {Project Name} Invoices (folder)
    • {Project Name} Invoices (optional)

• We use a self-hosted open-source version of Gitlab.com for code review and version control.
• URL for our private Gitlab server is at git.buildateam.io
• Gitlab is hosted on our Managed Google Cloud Platform
• Gitlab is integrated with app.buildateam.io for single sign-on
• All projects owned by the same company are located under the same group. Usually: git.buildateam.io/company-name
• Each project has its own git.buildateam.io repository link. Links are available in the project wiki.
• Project overview, tasks, comments and wiki are located under app.buildateam.io/projects/your-project-name
• Usually the repository link is: git.buildateam.io/company-name/project-name

Buildateam GitFlow

At Buildateam we work very similar as GitHub flow suggests.

Branches

Master branch for production version. This is the version deployed for all the clients.

Development branch for development version. All features deployed at development should be QA-Ready.
Feature branches will be created for every ticket/new feature

Commits

All commits should reference the ticket that belong to, e.g If the feature tracker-id is 180, then the commit should be as follows

git commit -m "180 Fixed component rendering"

Merging Your Branch. Pull Requests
Merge the new branch into develop branch after you have completed work. If no more work is required for that feature/bug – delete the branch related to the task.

New Releases

All new releases will be made every Wednesday at the end of the day. This day was selected because is in the middle of the week.
Hotfixes will be deployed as soon as possible and branches should be created as follows

git checkout -b hotfix-onboarding-product-listing
##Branch tagging

Branches tagging will follow semantic versioning.

How To Login To Git:

• Go to git.buildateam.io
• Click ‘Signin with Buildateam’

• Enter your username and password from app.buildateam.io and click login.

• Click ‘Signin with Buildateam’ again

Git Dashboard

All projects available for you will be displayed on the main screen after you login.

You can clone the repository or view commit history and repository code right from Gitlab.

Notes

1. Add a description / commit / link to the task if it is not in an app (gitlab issue, for example)

2. Just the link to any single resource that has the most current task description would work, even the google doc. There is no need to redundantly duplicate the same data over different resources

3. If its not the commit to the issue branch there has to be a link to the issue in regards to what the commit was made. If there is an issue branch than that data would have to be in Merge Request

4. At one time it is not recommended to write off more than 4 hours in timesheets

We are proud Google Cloud Partners and we offer Managed Google Cloud Hosting using Kubernetes, Docker, latest versions of MySQL, PHP, Node.js, Meteor.js, using Redis & Varnish for cache and framework optimized configurations for the most performance.

Continuous Integration with our private Gitlab server allows limiting access to production instance only for specialized DevOps engineers. When developers commit code to Gitlab it gets automatically pushed to the dedicated instance: staging or production.

Google Cloud allows an easy scalability of resources so during the middle of the sale season we can scale up and during the slow seasons reduce the load and spend.

Read more about Google Cloud and Kubernetes at Buildateam Academia:

How To Setup Scalable Magento Kubernetes Environment on Google Cloud.

How To Use Kubernetes, Google Cloud, and Docker.

Currently, we use Skype or Google Hangouts for video calls.

There are 2 group chats for every project in app.buildateam.io:

• {Project Name} – Support: for team meetings with the product owner
  • Demos and project discussions. Depending on the project involvement demo calls with the product owners usually happen once a week.
    • Agenda is shared prior to the meeting
      • What will be covered in the demo
      • Specific line items that were checked off or started since the last meeting
    • Take Feedback/Questions from product owners
    • Focus items from next week
    • Timeline update  (are we still on track, ahead, running behind)

• {Project Name} – Scrum: for internal scrum team meetings without the product owner
  • There are daily internal Scrum meetings for 15 minutes across every project where everyone answers 3 questions:
    • What have you been working on since the last meeting?
    • What will you be working on until the next meeting?
    • Are there any roadblocks?

We use an internally developed project management platform that is located at app.buildateam.io

Please follow the following steps to create a new product owner account:

• Create an account at app.buildateam.io/productowner
• Remember your username and password
• Go to your email box and verify click on the link that you should have received with subject: ‘How to verify email address on BuildaTeam.io – Dev Team On Demand’
• Go to git.buildateam.io
• Click Login with Buildateam.
• Enter the password and login from step 1.
• Tell your Project Manager that you have completed these steps, so that we can give you Owner permissions on your project and code.

Please follow the following steps to create a new freelancer account:

• Create an account at app.buildateam.io/freelancer
• Remember your username and password
• Go to your email box and verify click on the link that you should have received with subject: ‘How to verify email address on BuildaTeam.io – Dev Team On Demand’
• Go to git.buildateam.io
• Click Login with Buildateam.
• Enter the password and USERNAME from step 1.
• Tell your Project Manager that you have completed these steps, so that we can give you permissions on your project and code.

Please follow the following steps to create a new Agency / Team account:

• Create an account at app.buildateam.io/agency
• Remember your username and password
• Go to your email box and verify click on the link that you should have received with subject: ‘How to verify email address on BuildaTeam.io – Dev Team On Demand’
• Go to git.buildateam.io
• Click Login with Buildateam.
• Enter the password and login from step 1.
• Tell your Project Manager that you have completed these steps so that we can give you permissions on your project and code.

(if you don’t see the project information – request access from the PM)

All the issues from all the projects assigned to you will appear under Projects => My Issues Tab

Individual project overview tab contains a project description, project members and a total number of tasks grouped by type.

Project overview describes the main product objective, platform, and goals to achieve.

Project related logins and credentials for associated services are located in the Wiki. Please keep Wiki updated.

• Wiki mainly contains project access information:
  • Project Google Drive Folder URL:
  • Production Environment URL:
    Production Admin Panel URL:
    Login:
    Password:
    Comments:
  • Staging Environment URL:
    Staging Admin Panel URL:
    Login:
    Password:
    Comments:
  • Development Environment URL:
    Staging Admin Panel URL:
    Login:
    Password:
    Comments:
  • Domain Name Servers Editor URL:
    Login:
    Password:
    Comments:
  • cPanel / Hosting URL:
    Login:
    Password:
    Comments:
  • SSH IP Address
    SSH root account password
  • Git Repository URL:
    Production Branch:
    Staging Branch:
    Development Branch:
  • Zeplin URL:
  • InVisionApp URL:
  • Preferred day and time to deploy to production:
  • Preferred day and time for demo calls:

Use filters in order to adjust the displayed tasks.

To create a new task click ‘New Issue’ button either in the Overview tab or under the Issues tab.

• Click on ‘Active Projects’ in the left menu
• Select the project you’d like to create a task for.
• Go to the ‘Tickets’ tab
• Click ‘New Issue’
• Fill in the title, description, priority, due date and assign to the project manager or the responsible person.

When creating a new task please follow the following rules.

General Guidelines:

• A single task describes a single issue, bug, feature, request, user story.
• If a task describes multiple things, it gets broken down into sub-tasks or a checklist
• Depending on the project size video calls with screen sharing may be scheduled to better understand the tasks
• The more information is provided for the task – the less time would be spent on billable project management and communications
• Preferred way for any frontend tasks is to have designs or wireframes with the style guide at minimum
• The tasks are initially assigned to the project managers, who depending on the requirements assign them to the right person or team, schedule meetings if necessary and get estimates
• When the task is being worked on, its marked as ‘In Progress’ and % of completion is updated frequently
• When the task is completed it’s marked as ‘Ready for QA’ and assigned to the Project Manager / QA
• When someone adds a new comment to the project, the tasks needs to be assigned to the corresponding person
• All persons that need to follow the discussion on the ticket must be added as Watchers.

Task Content Guidelines:

• Title:
  • Bug: describe the issue in a couple of words. i.e:
    • Good: ‘Search bar on the category page for shirts is displaying incorrectly on iPhone 6s in portrait mode.’ 
    • Bad: ‘Search bar is not working’
  • Feature:
    • Good: ‘As a new user visiting the site I would like to be able to log in / sign up using Google and Facebook.’
    • Bad: ‘Add Social Login’
• Task Description:
  • Bug:
    • Good: 

      URL: https://www.website.com/support/storelocator/overview
      Expected Result: On this page, when I search for the Canadian province Alberta, all stores in that province are listed.
      Actual Result: On this page, when I search for the Canadian province Alberta, no stores come up. However, when I search for those store names or the postal code, the stores do show up.
      See screenshots attached for search results.
      Please revise so that when searching by Province name, the stores in that Province show up in a list and on the map.
      PostalCode.JPG (118 KB)’

    • Bad: ‘When I search for the Canadian province Alberta, no stores come up’

Issue Statuses:

• New – Ticket has just been created and needs an estimate.
• In Progress – While working on the task, mark it as in progress and update %% bar.
• Ready For QA – and assign to QA / Team Lead / Product Owner.
• Done – The product owner or project manager can mark the ticket as done after it has been released to production and QA’d
• Close – Ticket is closed without being completed (rejected).

Issue Priorities:

• Very Low – Solve whenever budget permits. (Almost meaning never)
• Low – Non-critical task that can be resolved after everything else is done. (Needs to be done)
• Normal – Non-critical task that is a part of the current or future sprint. Needs to be completed by the deadline.
• High – Critical features that can improve the business process or user experience.
• Urgent – Critical bugs and showstoppers that influence user experience and business processes.

Task Progress (Done, %):

Please update task progress on a daily basis. Since certain time estimates differ from the actual time required for the task, progress bar allows keeping everyone in the loop about the progress.

• Estimate submitted – 10%.
• Half of the task completed – 50%
• Ready For QA – 90%
• Done – 100%

Task Workflow

• Check tickets assigned to you on a daily basis and work on the most Urgent issues first.
• If the ticket doesn’t have an estimate – first evaluate the task complexity and add a time estimate.
• If the task doesn’t have a due date – ask the Project Manager about the Due Date.
• When you start work, please change the status of the ticket from New to In Progress.
• In case you have any questions, please assign the ticket to the Project Manager.
• Every day when you leave, please ensure that all tickets are updated about the progress made. Update the ‘% Done’ part daily.
• After completion of the work on a ticket, write your comments, change its status to “Ready For QA” and assign to QA or PM.

• In order to track time, enter the spent time into the appropriate (hour and minutes) fields in the comment view.
• Update the %, Done bar to reflect the overall status of the task.
• In the comment itself please enter:
  • Description of work completed for the time tracked as well as add links to:
    • Git commits from git.buildateam.io if its a development task.
    • Invisionapp / Google Drive link if it’s design
    • etc.

Timesheets

If time is entered on a regular basis, timesheets are available under ‘Timesheets’ tab. The data is filterable by date and user. Total time spent per task is also available under the issues tab.