Iterative development process works well for software development in general. Using a process like Scrum can however cause some problems with a high productivity platform like Drupal. With Drupal you already have a working product very early in the process, you tweak the details and in the end have an improved version. With Drupal features are cheap and details are expensive.

This post is the part 2 for my previous blog post on Iterative and incremental development for Drupal.

Iterations defined

Coming up with generic ideal iterations is very challenging. I fully expect to use different iterations for different kind of projects and project teams. Setting up the iterations should be a part of the discovery process before getting started on the development. The intention of this post is to provide a starting point for defining different iterations in each project.

Before we can start a project we need to do discovery. After the discovery we must at least have the following:

• Confirmed business requirements and how to measure them
• Risks and how to manage them
• Expectations, what promises have been made and to whom
• List of stakeholders and target user groups, ideally personas defined for each key user group
• A full backlog for the project, level of detail depends on the size of the project. In large projects stories just get bigger
• Understanding of the technical landscape, integration points, data migration requirements, etc
• Dependency diagram, what does the project need from external parties and by when
• Content delivery process defined, who’s responsible on what and how

We have internal tools and templates for everything that should be done in discovery. Some of these are already shared in our blog, others will be shared in the future.

Iteration 0: User story written

Responsible: The PO with support from the scrummaster and the team as needed

User stories originate either directly from the business goals or from splitting epic stories to something more manageable. An user story always has the following:

• As a WHO I want to WHAT so that WHY (or your own favourite user story format)
• Acceptance criteria
• OPTIONAL: How to measure success. This is a good discussion to have in order to understand the expectations of the PO, but it’s up to the team if they want to capture this or not.
• OPTIONAL: Technical notes. This is owned by the team and changing it only needs the team to agree on it. The reasoning is to keep technical requirements out of acceptance criteria in cases where they are not coming from the PO.

A great user story focuses much more on the WHY than the WHAT. At this point of the process we want to have a lot of flexibility for the team to implement this story in any way they choose.

Acceptance criteria includes limitations coming from the product owner, never from the team. The team may agree to do something, but only the PO can set official acceptance criteria. Acceptance criteria is often technical in their nature, say for example in an eCommerce payment story:

• Must accept Visa, Amex and MasterCard
• Must accept Paypal

How to do it

Many stories are already written during the discovery in a backlog creating workshop. During the project we’ll usually need more stories to be written. These can be written in backlog refinement sessions, in the sprint planning or in sprints as tasks. Each of these approaches has it’s benefits. By default I recommend that the PO and scrummaster together write the additional stories in backlog refinement sessions in each sprint. After this the stories are improved in sprint planning with the entire team as needed.

Definition of done

• All team members understand the story and the reasoning behind the WHY
• Acceptance criteria are unambiguous to all team members and the PO

Iteration 1: Potential solutions identified

The team or a team member identifies different ways to implement the story and meet the acceptance criteria. This is where we can make a big difference.

Think about if this is a Drupal implementation, would there be an existing SaaS service for this or some other way to meet the WHY. You are a web professional, it's your job to propose different solutions to the customer that may save a lot of work in the end.

How to do it

In this many heads are better than one. The recommended approach is to have the entire team and potentially also the PO spend a short session on this for each sprint. This may be time consuming, but coming up with an alternative solution may save up to 95% of the time required to implement the story.

Each task of defining potential solutions for a story should still have an owner. It’s the owners responsibility to do quick demo for the PO if required and to make sure the task gets done during a sprint.

Definition of done

• Drupal and non-Drupal solutions considered
• The simplest possible solution considered and proposed to the PO
• Multiple options identified
• Benefits, drawbacks and risks of each approach presented to the PO
• A quick demo shown to the PO when required for explaining the options
• The PO reaches a decision on which way to go

Iteration 2: Service design for the story

Now that we know which approach to take, we should move on to define the user process and experience.

How to do it

Typically the UX designer will create wireframes or other quick to implement solution to demonstrate this to the PO and to the team if needed. At this point the solution should not be a pixel perfect mockup, it’s still possible to choose another solution for the same goal so it’s not worth spending a lot of time on this. In order to do this the UX designer must understand the solution chosen, for example an existing Drupal module.

Definition of done

• User workflows understood by the PO
• Preliminary user experience designed and approved by the PO

Iteration 3: Functional prototype created

It's time to implement the chosen workflows and UX. This step only includes a minimal version of admin functionality, no testing or QA. The intention is to make sure we are building the right thing before paying more attention to detail.

How to do it

A team member implements the quickest possible prototype that demonstrates the user experience to the PO. This can then be used as a demo for the stakeholders of the project as needed, assuming the stakeholders can just focus on the functionality instead of the visual details.

In some cases there is very little difference between functional prototype and MVP, in these cases these two iterations should be merged. However if there is uncertainty if the PO or key stakeholders to the project understand what we are about to do it’s well worth doing a separate iteration for functional prototype.

Definition of done

• The primary end user workflows can be completed in the prototype
• User experience is mostly according to preliminary designs, not pixel perfect

Iteration 4: MVP implemented

The team and the PO get together with the functional prototype and decide what parts still require attention.

How to do it

Based on the feedback from the functional prototype multiple team members get to work. Remaining details are defined and implemented. The goal is to have a minimum viable product, this means something that could be released but is not yet ideal.

Definition of done

• A potentially publishable piece of functionality, only waiting for QA in order to go live
• The project definition of done -QA
• The PO approves the MVP

Iteration 5: QA implemented

Implement the automated testing and any other QA measures defined in the project. ( a template should be provided )

How to do it

This is mostly technical task, getting all of the quality assurance in place to make the story implementation easy to maintain and make continuous deployment of incremental improvements possible.

The iteration also includes making sure the story meets production check-list, unless this has been agreed to be done per release instead of per story.

Initially we should always only do the MVP instead of trying to reach ideal implementation. According to the pareto principle it’s often more valuable to move the focus on the next story instead of tweaking this one. The team should still allow for more time to get back to improving a story and remind the PO to evaluate the priorities between improving a story vs starting on new stories.

Definition of done

• The project QA definition
• Production checklist completed (per story or per release)

The life of a story after the MVP

We are not aiming to do ideal implementations for each story right away. This is important because sometimes priorities do shift during a project when we learn more. It’s also often useful to get a MVP version to the hands of real users and see how it performs before aiming for the ideal version. Sometimes our assumptions on what’s ideal are not spot on after all.

However the goal of a project is not to simply deliver a MVP. For some less important stories a MVP may be enough, but the more important wants definitely require more attention from the team.

Improving a story can either follow the same 6 iterations outlined in this document or be much more specific, basically just a task on focusing on one area of the story implementation. Typically it’s more common to just focus on tasks improving a story.

At this point it’s important to be careful not to end up delivering over-quality. This means a very high quality product technically, visually or by any other aspect that will never have any return on the investment made on it. It’s worth mentioning the cost of doing an improvement in money (based on best guess on hours spent) to the PO and get her to confirm she thinks it’s worth the investment.

Areas of improvement to consider

• Admin experience improved
• User experience improved
• Adding new functionality to the story
• Better total cost of ownership by making maintenance easier