Principles for the development of a big project

This article was originally posted in the Ontruck Product blog.

At Ontruck, we don’t usually do big projects. We try to work on incremental improvements which help us validate the solution along the way. However, every year we have two or three big projects which can’t be broken down and require us over three months of development.

We are in 30% into a new big project, which in fact; it’s a refactor and redesign of one our products. To be more predictable, and reduce the risk, the squad is applying the following principles to the project. They won’t be new for many of you, but it’s healthy to remind them.

Split into small user stories
Big User Stories should be broken into stories of 1–3 points. We are going to do all, but with smaller stories, we can divide the work and estimate better.

Document at the same speed we build
We need to have all documentation of business logic in the wiki at the same time we build. Apart from using the Acceptance Criteria, we can test with the documentation.

Delay product specs which require complex logic
We will push back anything that adds unneeded complexity, and it’s in our path to test it soon with users. However, we will take it into account when building.

Re-evaluate the estimation continuously
We will re-estimate each story once we have finished it. With that info, we will re-estimate the next stories. The objective is to be more precise.

Have a global overview of all user stories
Every Monday, we check the status of each user story. That way, we can anticipate blockers and future needs.

Launch internally every week
We should break the project into many internal phases. The objective is to avoid a huge team testing and some long and painful bug-fixing weeks.

Launch to clients as early as possible
We want to test it soon with users to detect UX issues which can’t be caught on design prototypes. We want to have clients using it early on their day-to-day.