-
Notifications
You must be signed in to change notification settings - Fork 4
Ways of working
We have three different types of tickets that we use to track work. These tickets types are aimed at ensuring that all of our work is focused on our users.
These ticket types are:
-
Research Used to further understand a problem, framing it, ready for the design work to begin. All work should begin with a research phase.
-
Designing the solution Design in this sense can refer to service, interaction, or technical design. We'll be coming up with ideas that we think will provide an adequate solution to the problem as defined in the research phase. In order to test those ideas, we won't build anything more than a prototype or proof of concept. Sometimes it will just involve sketching out a solution to the design problem. We'll include some kind of feedback mechanism in this design stage - normally useability testing - to ensure we've solved the problem that was identified during the research.
-
Implementation The work of taking a design from the previous stage and making it production ready. Everything we put into production will need feedback or to be monitored.
Each of our ticket types will have its own swimlane to differentiate the activities of research, design and implementation.
All swimlanes have these columns in our JIRA board and tickets move from left to right:
- For Analysis
- Ready to Play
- In Progress
- Rollout
- Done
We'll spend a little time - through regular prioritisations sessions - looking at the tickets and giving it a priority based on what we know about it at that time. At the start of this prioritisation session, we'll review the Done column to see if we have enough work to justify a release.
Example planning session agenda
- Review work Done
- Discuss tickets in For Analysis
We'll conduct a three amigos session to move tickets through the columns on our board and team feedback sessions to move tickets from research through design to implementation. During this session, we'll decide if a ticket needs a sizing, either timebox or t-shirt.
Before a research ticket is moved from the 'For Analysis column' into the 'Ready to play' column, it must have the following:
- Acceptance criteria for being ready (research question)
- What we think the problem is and why it’s a problem
- Who we think this problem affects
- How we’re going to validate the problem exists
- How we’re going to investigate the problem
- Should be labelled 'research' in jira
Before a design ticket is moved from the 'For Analysis column' into the 'Ready to play' column, it must have the following:
- Can only be created with a link to a done research ticket
- Acceptance criteria for being ready
- A link to the preceding research ticket’s artefact for the solution
- Hypothesis
- Ideas to explore
- Acceptable resolution to the problem
- Should be labelled 'design' in jira
Before an implementation ticket is moved from the 'For Analysis column' into the 'Ready to play' column, it must have the following:
- Can only be created with a link to a done design ticket
- Acceptance criteria
- A link to the preceding design ticket’s artefact for the solution
- Steps to implement the solution
- Rollout plan
- How we measure/validate the usage of the solution
- Rollback/Rollforward plan
- Update any required documentation/changelog/release notes
- Should be labelled 'implementation' in jira
We class anything that is going in front of end users as implementation. This includes putting content - such as documentation, that has been developed during design - into the final place.
- The scale of the problem: how many users does this affect?
- Capture findings in GitHub.com and/or confluence
- Present findings to the team and the best way to show/demo this
- Tested and validated that the design solves the problem (not limited by tools we can use)
- Findings of all resulting designs considered during the ticket presented to the team
- Proof that the solution’s being used by real users
- Some form of feedback about whether the solution works