The process we adhere to is a blend of a couple of different principles and philosophies (e.g. Agile, XP, Lean). It is a moving target and we tweak it as we learn.

The gist is that we a follow prioritized plan – or backlog – that we work on in iterations. A new release of the project is launched and demonstrated after each iteration (typically 1 - 2 weeks).

The process described in this document allows us to:

  • Eliminate waste and reduce time to reach a usable product. The project plan can be re-adjusted after each iteration or when new business needs are discovered.
  • Increase predictability and manage expectations. New features are shipped frequently and deployed through a continuous delivery cycle.
  • Focus on the value delivered and obtain rapid feedback. The client plays an important role in deciding the order in which new features are added.
  • Improve quality of the product. Breaking the work down into mini-releases allows us to continuously test and review the product.
  • Increase trust and ensure clear communication. Everyone knows the state of the project and what is being worked on at any given moment.


We start with a discovery phase, break initial requirements down into manageable units of work, work in iterations, and learn and adapt from each iteration.

Initial research, discovery, and planning

We do enough research and discovery to understand the primary user and business needs. We look for insights that help us identify what to focus on, uncover unspoken needs and opportunities, and obtain a fundamental understanding for the domain. Our goal is to understand the vision and to gather enough information to get started, but we leave room for changing requirements.

The initial phase should result in:

  • An initial, prioritized backlog of work to be done
  • A short document containing:
    • A brief description of the product
    • A list of users of the product
    • Any non-functional requirements known at the time
    • A list of who fills what role (delivery lead, product owner, and important stakeholders), including relevant contact information
  • A plan for the first 1 or 2 iterations
  • A general system architecture and plan (time frame, tools to use, skills required etc)


The project is broken down into manageable units of prioritized work that are placed in a backlog. Units of work can be inserted, removed or re-prioritized instantly at any time during the project as business needs change or feedback is obtained.

Units of work in the backlog are then boxed into weekly or bi-weekly iterations. Daily sit-down meetings are held to ensure a tight communication loop and every iteration ends with a demo and a review.

After an iteration is completed the latest version of the project should be merged into the main branch and deployed, and the next iteration should be planned.

Each work unit (single developer or pair) should never work on more than one unit of work at any given time.

Partitioning work into iterations is a means of dividing work to be done and is a crucial part of planning. Zealously completing all units of work for the sake of it, however, is not always the end-goal. It often is, but the real goal that we cannot loose sight of is moving the project forward in the right direction. Not completing an iteration in its entirety is often ok.

Note: There are many different ways to describe the units of work mentioned above. How we describe them depends on the project, but we typically follow the format described in User stories, tasks, and bug reports.

An alternative to time boxed iterations

An alternate approach is to forego the time aspect of the iterations and instead focus on delivering work as soon as it is ready (i.e. keep the iterations small and consider them done when they are done). This approach works well in some types of projects and has a couple of impactful benefits:

  • No time spent trying to estimate time and how much to fit into an iteration
  • Updates are delivered as soon as they become available (which means the work will be tested in the wild earlier – something that may lead to earlier access to insights that can impact upcoming work)
  • Prioritization is done in real-time (after each delivered unit of work)
  • Reduced time pressure can help mitigate the risk of de-prioritization of tests, reviews, or other things that may affect quality
  • Enables management of projects where continuous time to work is limited (e.g. side-projects)

Yet, for all of these benefits, time is often an important factor in certain real-world projects. Resource-use must sometimes be reliably predicted and stakeholders must often be able to make schedules based on certain dates.


Delivery lead

The delivery lead organizes the team and project as a whole. He/she coordinates the distillation of the requirements and the translation into the technical solution that can be communicated to both team and client. This is often a dedicated role, but it can be a person that actively participates in the development in smaller projects.

Responsibilities include:

  • Schedule and coordinate meetings
  • Keep a birds eye view on project schedules and resources
  • Help estimate, prioritize, and coordinate tasks and iterations
  • Help communicate product goals, milestones, and priorities
  • Conduct final reviews (e.g. code reviews, merges topic branches)


The team consists of developers, designers, testers, and architects working on the project. It may also contain sub-contractors engaged by either party.

Developers are typically divided into pairs that employ strict (i.e. work side-by-side pair) or loose (individual work with code reviews) pair programming during the bulk of the work. The other team members (e.g. designers, operations, architects) work tightly with the developers during iterations to ensure good communication.

Product owner

A person that conveys the product vision, mission, and provides domain expertise. He/she represents the client and must have authority to say what goes into the final product.

The product owner is responsible for:

  • Convey an up-to-date version of the project goals
  • Prioritizing strict requirements making it clear to the team what is most important for the project from the business’ perspective
  • Providing information about the domain, business, and stakeholders
  • Coordinating stakeholders

Other stakeholders

Anyone that is directly or indirectly affected by, or otherwise related to, the project (e.g. client’s customers, users of the product, other development teams, IT, legal and compliance, marketing, managers, domain experts). Relevant stakeholders should be identified and their roles established at an early stage.

There is one stakeholder of particular importance that is present in every project: the end-user. The end-user is used directly or indirectly to prioritize requirements to ensure that they deliver value.


Daily sit-down

  • Who: Delivery lead and team
  • When: Every day

A short (normally 15-20 minutes) meeting where the team coordinates itself and the current iteration. It is also a forum to share quick insights related to the current iteration or the project as a whole.

The developers take turns to describe what they did the previous working day, what they are going to work on today, and if there’s anything blocking or impeding progress. The developers are also encouraged to describe how they plan to tackle problems so that their plan of attack can be briefly discussed with the team.

Iteration demo

  • Who: Product owner, delivery lead, and team
  • When: At the end of each iteration

The result of the iteration is demonstrated by the team. Feedback is collected and recorded and may result in new units of work in the backlog.

Iteration review

  • Who: Delivery lead and team
  • When: After the iteration demo

After the demo the team members share what went well and not so well during the iteration and discuss how the process can be improved for the next iteration.

Iteration planning

  • Who: Delivery lead and team
  • When: After the iteration review

Plan the next iteration based the priority of items in the backlog. Units of work can be further broken down and re-prioritized within reason (judgement calls can be made if synergies between some units exist or if there’s something blocking work from being carried out). The units of work are estimated and moved into the next iterations(s) based on whether it is feasible or not to complete the work during the iteration.

Sufficient time should be added to properly test and review the work being carried out during the iteration. It’s oftentimes better to be a little conservative and finish the iteration early or add another story, than to remove something from the iteration when time is running short.

It is important that everyone gets their say when planning an iteration. The people in the trenches often have very valuable insights about, and an intrinsic understanding of, what they’ve been working on and can identify problems or potential benefits that might not be immediately obvious.

Backlog management

  • Who: Delivery lead (and, as needed, the team) and product owner
  • When: As needed

While the current backlog should be reviewed continuously, it is often good to schedule a meeting once in a while to ensure that all work units are still relevant and correctly prioritized. The goal with the process is to:

  • Ensure there is a sufficient backlog of work to cover 2 - 4 iterations
  • Proactively adjust the backlog in line with new insights and that it correctly reflects the current goals
  • Correct estimates in light of new discoveries
  • Split work units into smaller work units in order to fit them into an iteration

Requirements that do not have enough detail (ideas for future versions, broad ideas that do not yet have an implementation plan due to unknowns etc) to be implemented within the next couple of sprints are pruned from the backlog.

Related entries