90 Sprints for Capital Markets – Part 2

In the first part of our series, we took a quick glance at some fundamentals, such as the very utility of agile processes in huge organisations. Now let’s turn to the more practical, down-to-earth pieces of the puzzle.

Myth #6: “Planning a meeting is boring”

It is, assuming that you try to estimate all stories and plan the whole sprint during a single meeting. Even with two-week Sprints, it may take an entire day’s worth of work. We run a product backlog refinement session weekly, which takes no longer than one to two hours. Using standard techniques such as planning poker, we review, analyse and estimate stories. We focus on asking questions upfront, and on marking the tasks that need answering. With the help of a Product Owner, all stories need to be clarified before the planning meeting. A good approach is to review items for two Sprints ahead. When the team understands the requirements, a given item is marked as “Ready for development” and only such items are taken into account for the Sprint. As a result, the combined review and planning meeting usually takes just around an hour.

Myth #7: “You don’t need to write documentation in Agile”

Documentation is a necessary part of software delivery, no matter which process you employ. However, in Agile you shouldn’t write too many detailed design documents upfront. Literally every single requirement document prepared upfront will be subject to change! The key is to find a way to handle these changes, track history, and always make sure that the current version is readily available. Instead of using documents and emails, a good issue tracker works best.

• The overall concept, process – the big picture goes to the Epic
• Then it is divided into stories, which go into the details
• Once the initial stories are implemented, the remaining ones from the same Epic usually change
• Extract nice-to-have additional features into separate stories to implement later (or never!)

Keep all communication for a story as comments underneath it. When requirements change, leave a note. We use it as an online discussion board instead of emails, and as a result we have a single, searchable repository of requirements and change history together with discussions and notes. Moreover, documentation prepared this way “lives” – each story has an implementation and testing status.

In Agile, you still provide user documentation, technical documentation, production support guidelines etc. as you go. Just don’t spend weeks upfront on design documents.

Myth #8: “Agile means that requirements can change at any time”

Requirements will change. This will always happen. Agile provides a framework that allows you to change requirements in a structured way. Changing requirements is a normal part of the process. Everybody should feel comfortable with change. Mutual understanding is required to make sure that the changes don’t come late in the game, as this can cause throwaway work.

At the same time, the development team understands that building the first working version of a feature will most certainly change the shape of the following User Stories. For us, it quickly turned out that business users are happy to see early versions of a feature in order to verify the idea and take part in the process. Sometimes it just means to fail fast and start over. We’re talking about capital markets: requirements can be very complex and heavily interrelated. Mistakes can be expensive, so it’s better to test and fix twice.

The first thing to do when we receive a long description of the required business process is to split it into smaller Stories and move them to the issue tracker. Each of the Stories is then clarified, supplemented with details, divided into smaller parts if needed, or – from time to time – even closed. Each of the Stories “lives” – it has its own history of changes, comments, examples and test cases; all this information stays there. Initially, there were attempts to keep the original design documents up-to-date, with limited success. However, keeping the big picture description of an Epic and individual Story descriptions up-to-date is sufficient. It’s better to spend the saved time on building user and production support documentation.

Myth #9: “You don’t design architecture in Agile”

Actually, this is one of the hardest parts of Agile delivery. You do design the architecture! Although you don’t have a formal document for this as part of the process, there is the so-called “Sprint 0” that you can use for the initial design phase. Some diagrams and an overall architecture vision must be produced. The most important rule is that your architecture needs to be designed in such a way that it can adapt to change. Just like Clean Coding, you’ll come across many Clean Architecture design principles. Most architectural patterns are well described and have their pros and cons, so don’t try to invent anything new. Just keep in mind the potential costs of changing the moving parts of the system, and be prepared for continuous refactoring. Architecture cannot limit you. Changes will come, despite the process you pick. However, in Agile, you design with change in mind from day one.

Myth #10: “The Product Owner just needs to prioritise the backlog”

A backlog is never flat. Treating the backlog as a prioritised list of user stories is naive. Don’t hesitate to add more dimensions to the backlog rather than just priority. Your backlog’s organisation will depend heavily on business stakeholders. However, you will always have main deliverables to be implemented in a certain order, some nice-to-have improvements to add in the meantime and bug-fixes coming up here and there, as well as pure IT tasks. The amount of work is often too big for a single list. The main problems we’ve encountered are as follows:

• The team reviewed items that were not the actual priority, but landed on top of the backlog by mistake
• Important items were lost at the bottom of the backlog or raised just before sprint planning. Too late to analyse!
• The Product Owner or business stakeholders get lost in a huge backlog
• Unclear plans for the near future

We’ve spent many retrospective meetings trying to put some structure into the backlog with a few failed attempts. Let’s take a look at an example:

• #NOW is a list of items that the team is actively reviewing and planning for the following Sprints. Keep it short: two Sprints at most. Items that remain in #NOW for too long fall to #NEXT
• #NEXT is a bucket for top priority for the near future
• #WAITING ROOM is a list of new stories, bugs, issues actively reviewed, triaged and prioritised by the Product Owner and analysed by the team. No new items land on the bottom of the backlog by mistake
• A separate list of #IT4IT work, to prevent “polluting” the product backlog.

Apart from priority, bucketing items are grouped into Epics. They are linked together and labelled as, for example, status, estimate, priority, severity (bugs), category, component etc. – all for easy searching. If you group items into Epics or components, you can say how “wide” your backlog is based on the number of different areas it touches. It might be easier to organise such a three-dimensional backlog: “length” x “priority bucket” x “feature”. Consider trying Roman Pichler’s Product Canvas, which may be very useful here.

See you in next week’s episode, where we will take a closer look at Sprints.