Our process

Get the most from software development practices like Agile, SCRUM and XP with proven best practices and tools.

Project Kickoff

Every successful project starts with a team that's firmly aligned and prepared for product development. At Def Method, every project starts by collecting product requirements, aligning with your team on goals and expectations, and building a prioritized project estimate.
The primary goal of the kickoff is to get alignment among all team members: clarify the key goals and the anti-goals (what we will not do) for the project, identify key constraints (launch date, market conditions, budget) and risks factors, and establish the prioritization of features. Once we've completed this process with your team, we'll have the information we need to dive in head-first to product development.

Progress Tracking

Our PMs are flexible and adapt to each client's needs while advocating agile software development principles that have proven to be successful in driving quick iteration, efficient prioritization, and continuous risk reduction. The process includes daily standups, weekly IPMs, weekly demos, and project retros.While we are flexible to work with your preferred tools, some commonly used tools are Pivotal Tracker, Trello, or Jira. We typically use Slack for communication, Google Hangouts/Meet for remote meetings, Rollbar for error tracking, and New Relic for performance monitoring. Using a data-driven approach, we ensure that your product is making healthy progress by continuously measuring and analyzing key success metrics defined in the Discovery.

Maintenance

A natural course for many products is moving temporarily from active development of new features to ongoing maintenance.
As part of our development process, we implement the appropriate tracking tools to ensure your application is effectively monitored. This includes error tracking and performance monitoring tools with appropriate notification settings and user tracking tools such as Google Analytics, Mix Panel, or Heap. At Def Method, we stand behind the products we build, and you can rest assured that your application will stay up and running with an engineer keeping your codebase up-to-date. We offer maintenance plans for customers that are interested in having the option for the development of small features, bug resolution, and other maintenance activities.

Daily Standup

15-min standups

The daily standup is a quick check-in between the developers and decision makers on the project. Standups are expected to run less than 15 minutes and each team member in turn shares what task they worked on the previous day, what task they are working on today and if they face any “blockers” or obstacles. Decision makers can help remove any obstacles or answer any clarifying questions on the active user stories during these meetings.

Learn More

IPMs/Retros

Iteration Planning Meetings (IPMs)

Iteration Planning Meetings (IPM)s also known as Sprint planning occurs once every week or every two weeks depending on the project needs. At this meeting the team together review the user stories that they will work on for the following sprint, clarify the acceptance criteria and point the stories. Once all the stories are pointed they will use story points as a guide to commit to completing a unit of work during the sprint. At the end of the sprint the team will demo their deliverables to the client and other stakeholders.

Retrospectives (Retros)

Retrospective meetings are held once every week or every two weeks depending on the team. Retrospectives allows the team to evaluate their progress, share what worked well for them and what created friction in their work during the past sprint. Regular retrospectives allow the team to check in frequently and run mini-experiments to improve workflow and become more efficient as a team. The retrospective aims to answer the following questions:
- What should we stop doing?
- What should we continue doing?
- What can we start doing that will help us be more efficient?

Learn more

User Stories

Story Writing

We write requirements in the form of user stories using the format:
As a <user>, when <action>, I want <a feature=""> so that <user goals=""></user></a></action></user>
‍

‍Writing stories this way keeps the business and engineering teams focused on the end user and guides product design and development according to the needs of the target user. Once we have defined each user story, we add functional and non-functional requirements and acceptance criteria that need to be met for the user story to be considered completed. We break down our user stories to make sure each user story is small enough to be done within 2-3 days to ensure ongoing progress and prevent blockers.

Story Acceptance

Our engineering teams deliver continuously and you, the client, play the primary role in reviewing and accepting delivered features. As soon as a user story is complete it is put in a queue for you to review and approve. To facilitate the review and feedback process we hold weekly demos of the delivered features with the engineers. This is where you provide feedback to the team on what you see. The ongoing nature of the review and feedback process throughout development allows you to call in adjustments as the work is being done reducing significant rework and redesign. It also provides full transparency to you with regard to the progress and quality of work being conducted.