Today’s episode will be devoted to planning, analysis, and building architecture.
Workshops vs grooming
The tasks of our team can generally be divided into two categories:
- error correction, minor streamlining and modification, building small components,
- building large components, functionality groups (i.e., something akin to a project).
In our work besides Sprint Planning we also use grooming (or what the latest SCRUM guide calls Product Backlog refinement). It usually takes us 4 hours in a 2-week sprint. And this is where the problem, or, rather, a handful of problems connected to the grooming of large components surfaced:
- 4 hours is certainly too short a time to “develop” a large component well. This elicited something the team called “coitus interruptus”. Dreaming of a single component continued for many sprints, which naturally had a detrimental impact on its efficiency.
- During the analysis, the team frequently missed certain functional areas (and non-functional as well). This resulted in the volume (i.e. labour intensity) of the component “swelling” with the progress of work on the component.
- Most of the grooming sessions were “remote”, that is they were telecons between the team and the Product Owner, for which reason it was quite difficult for the developing team to collect all the significant information.
- Frequently concept problems evolved because developers failed to understand the business assumptions (business model).
To solve these problems, we introduced so-called Workshop. It is actually a structured form of grooming that always takes place face-2-face (Project Owner with the team work together at the same location). Introduction of this new name is very significant, as it signals to both business and developer party that grooming:
- concerns a larger functionality/component,
- cannot take place “remotely”,
- has a specific structure,
- will last longer than usual.
As a rule, our Workshops last whole day (8 hours) and are divided into three parts:
Participants: the whole team (together)
Maximum time: 1.5 h
1. Introduction – Scrum Master reminds/informs how a workshop is organised (i.e. presents the agenda below).
2. Identification of the area of the works – defining which functionalities/components we will address during the Workshop. This is usually done by the Product Owner.
3. Presentation of the vision of the functionality/component:
a. business goal of the functionality/component,
b. long-term business plan related to the functionality/component,
c. which group of clients does the functionality/component concern,
d. what market it addresses,
e. potential problems/challenges.
While working on this point of the Agenda, the Product Owner presents the vision connected to the business side of the project to the team.
4. Agreeing the goal(s) of the Workshop: goals are best written down on a flipchart. Examples include defining the high-level estimate for the XYZ component, agreeing the architecture, breaking the works into epics.
5. Division into Workshop teams: due to the size of the team we break down into smaller groups of 4 or 5.
Held in subgroups.
1. Identification of actors – brainstorm aimed at drawing a list of all potential actors (users, other systems, etc.).
2. Identification of functional and non-functional areas – brainstorm to build the list of all potential functional areas.
3. Creating the epic matrix.
The team builds a matrix with actors defined in rows and areas in columns.
4. Identification of epics (user stories) – an epic or user story is developed for every cell in the matrix (actor-area pair). We don’t enforce their creation. If a given epic does make sense, we leave the cell empty. Thanks to this approach, we “look” at the system from various perspectives and minimise the risk of overlooking an area.
5. Defining priorities for epics/user stories (essential, important, nice to have) – this is how we prioritise the epics. We have three categories: essential – absolutely necessary for production to start, important – we must do it, but if it comes to the crunch, we can pass on to production without it, nice to have – it would be cool to have the functionality, yet we can live without it.
6. Bring the epics/user stories into product backlog.
7. Development of base architecture – discussed further below.
8. Estimation of epics/user stories – very general (by assigning T-shirt sizes), yet also examined further below.
9. Breaking epics into User Stories – if time allows :-)
All together max 30 minutes.
1. Is the goal/Are the goals of the Workshop achieved?
2. Follow-ups? – What should the follow-up connected to the groomed element be (initial action plan or further grooming plan).
3. Roundup – a few comments from the Product Owner in nutshell.
This is more or less a plan for the Workshop. Sometimes it undergoes slight modifications to allow adjustments to the specific Workshop goals.
Closing let me mention yet another forte: even if not all the items on the agenda have been covered, we know precisely where we finished and we can easily continue work at the following Workshop or grooming.
To meet the requirements of our Product Owner and to improve the clarity of information passed on to “business” we introduced a three-degrees scale of estimation.
- Shoot from the hip – measured in T-shirt sizes. Each size has a story points interval assigned, and the greater the size the broader the interval (for example XL corresponds to 50 – 90 SP). On the one hand, such an estimate allows Product Owner to define whether it makes sense to deal with this functionality, and on the other in a way it gives peace of mind to the team (a step aside from Story Points), and in this way, they lose no time trying to estimate everything perfectly.
- RAW-estimate in story points, with values taken only and solely from Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55).
- Rough but ready – in Story Points. Precision up to 1 SP, with a maximum value of 13 SP. Only User Stories with this level of estimate can be included into Sprint Backlog. This prevents ”dragging” too big (and through this, unclear) stories into the sprint.
I’ve left for the end the question of system architecture, very difficult in agile. I’ve heard and read plenty of comments of the type “in agile we NEVER create architecture up-front. We re-factor.” BALDERDASH!!! It’s evident that people spreading such theories have never had any experience of major projects already operating at production level. I wish them luck with all implementations while modifying several dozens of components disseminated over several server clusters. Agile is agile: you do it so that it is optimum for your project. You don’t have to do up-front architecture – cool. You win. Unfortunately, we have to. Albeit we try to maintain it at a certain level of abstraction, and not fall for the details too much. We do it during a Workshop or grooming, because without high-level architecture being decided, it is difficult to give estimates for a given component.
Author: Piotr Jachimczak / Software Development Manager