Last week, I ran a couple of workshops with the Vision Tasks team to help us better understand our processes.
As the Vision Tasks team in its current guise is a relatively new team, I thought it might be a useful exercise to map our development and testing process, starting from the point of adding a user story to the backlog to that requirement being ready for deployment.
Business process models such as these are helpful for newer members of a team who perhaps don’t yet have a full picture of the team’s processes and how their role relates to others on the team. This ‘as is’ or ‘current state’ visualisation can also draw out inconsistencies, promote a consistency of approach and identify areas where improvements can be made.
Business process maps have five important components: actors, tasks, flow, decisions and outcomes.
We identified the main actors (the people who carry out the tasks): product owner, developers, testers, UX designer and scrum master. Then mapped out the tasks, flow, decisions and outcomes on flipchart pages using post-it notes.
I later created an electronic version (above) which is currently on the wall in the Dundee office, inviting feedback. It would be interesting to know how close our process is to those on other teams sitting around us.
It was immediately clear that there are a few areas where we could drill deeper and clarify some of the loops during the development/testing dance but for our purposes this was a really good start.
With the development/testing process mapped out in front of us, taking one requirement from user story to finished, working software, I then asked the team to come up with their own definition of ready.
In other words, what information does the team need in their Jira ticket before they start coding to be able to most effectively deliver that requirement?
Having the process visualised before us meant we could make sure every aspect of the workflow was considered.
This was the definition of ready we came up with:
- Story or task must exist and be understood.
- Description must have enough background info for team to understand why this is being done (including input from stakeholders).
- Any required UX is provided (screenshots where appropriate).
- The acceptance criteria is agreed and documented.
- Any investigations and spikes are completed.
- Story or task has been estimated by the team.
- Story or task has been assigned to a version.
- Implementation is understood by entire team (and any helpful notes and suggestions from discussions are recorded).
- No stories more than 13 points (or anticipated to take longer than one week) will be taken into the Sprint.
- Spikes must take less than two days.
We used it during the next sprint planning meeting and will review it in future retrospectives. The next task is to use the same process map to write our definition of done—in other words, when is a story fully implemented so you never have to return to it? When is it not only done but ‘done done’.
Originally posted on the Vision internal blog.