Effective Scrum: Melba's Sprint Workflow

By effective we mean:

• Working on the right topics
• Making predictable results to be obtained after a given period
• Having a suitable capacity to work
• Putting into production regularly
• Not having a regression during production releases
• Iterate by increasing our capacity to work
• Satisfy the development team and the entire company

Prerequisite

Before trying to organize the work of a development team effectively, it is important to determine a coherent scope of work. We have achieved this through the implementation of a  quality product process.

This assumes that we have succeeded in determining precisely the next functional priorities:

• these priorities stem from the need expressed by users and from strategic initiatives that serve our vision
• they are accurate - the work of UX and UI has removed doubts that the solution meets the need

The team must also share the scrum philosophy and someone must have a positive experience of its application. This is the case with us as one of our lead developers practiced it ardently.

We were also able to realize our early mistakes when reading  Scrum in Action  by Guillaume Bodet. The book describes a rocker that we have experienced, from working in a V-cycle to applying scrum. A contract with a large group had given rise to the drafting of voluminous specifications. The need was not clear to anyone, changed frequently and the demands of our partner and our desire to comply with them led us to sacrifice quality: we had fallen into a vicious circle where urgency pushed us to botch and put in production every 3 months to realize many regressions and a mismatch with user needs.

Scrum is a communication tool. Scrum enables teams to synchronize effectively, work on things that matter, and reap the benefits quickly. To be anti-scrum is not to want to communicate effectively.

Today Melba puts very small tasks into production 2 to 5 times a day without regression. Our users give us feedback every day that we are able to process quickly.

Preparing for sprints

We chose to work on short sprints: 1 week.

This increases the overhead  but decreases the preparation work and allows you to be more agile. We could adapt the slider and choose to reduce the overhead  by increasing the risk associated with setting a larger functional perimeter. 

Risk:

• that the tickets lack preparation as the need changes
• that external elements disturb the sprint (bug to be solved urgently...)

Because a sprint is exactly that: freezing the development team's to do to allow it to work in comfortable conditions, without interruption and without change of direction. The development team knows what to do for the next week and no one is going to bother them.

The sprint is made up of user stories (US).

Before going into detail, here is a Trello card  representative of a US below. Its content is described in the following paragraphs.

Example of a complete US:

A documented user story

A US takes the following format:

As <persona>, when I am in <context>, I want <action / result>

We also define the  Why: why is it important, what is the user's need.

Finally, we add a link to a model and other resources that may be necessary (font, pictogram, image, etc.) in order to limit the research time of the development team.

We link the US to our wiki which summarizes all the acceptance tests as well as to our static API documentation. This static API documentation, modeled after that of Stripe, is to backend development, what mockups are to frontend development  .

Each US can be put into production. If it is part of a course whose minimum set is not yet ready to be shared with users, it is nevertheless put into production and hidden.

Note: we sometimes make the difference between  user story  and  job story.  Melba instead does job stories that include context, while user stories traditionally doesn't.

Acceptance tests

Acceptance tests include the business logic elements that the functionality must satisfy. It is interesting to divide the US into small-scale elements so as not to impose too complex a logic and thus more easily identify edge cases.

Acceptance tests make it easy to see the result: the developer who finishes their work must check off the various elements, which indicates that they have verified that the expected result is obtained. If expected behaviors are not listed in these acceptance tests, the PO must create a new ticket.

The  refinement backlog

The refinement backlog is an opportunity for the PO, the UX and members of the development team to go through all the tickets anticipated for the next sprint (or even a little more) in order to eliminate misunderstandings, inaccuracies, risks, etc.

Workshops and presentations of design work upstream of the  refinement backlog  make it possible to sensitize the technical team to functional issues, but during the cutting we enter a level of refinement that makes this exchange necessary. The business knowledge of UX and PO is shared and the technical team helps to make trade-offs that go in the direction of a better ROI. 

Technical cutting

A second exchange is planned before the start of the sprint to allow the technical team to specify the technical to do. On this occasion, each functional task is technically broken down.

The challenge is to remove all points of doubt so that there is no unknown during development. Thus, we go so far as to name certain classes and methods and explain what will be done and how, collectively, between developers. This is an opportunity for seniors to pass on their experience to the juniors rather than just imposing a misunderstood to do on them or letting them flounder.

Example of a precise technical cut:

If the technical cut is not possible or is uncertain, then we won't be sure how to assess the complexity of the task and we will have to timebox the time spent on it to avoid getting too lost. We will come back to that.

The  schedule sprint

During the planning, the development team is accompanied by the PO who reviews the various tickets.

This planning is not a pain as it could have been in the past when the team discovered needs incompatible with its capacity to make or still conceal enormous unknowns. The upstream collaboration has borne fruit.

The planning poker

The capacity to do is estimated in points of complexity. This does not strictly correspond to available working time. However, we deduce from the theoretical suitable capacity to do and the time taken by events not associated with development (meetings, interviews, etc.). On this occasion only, we make the amalgamation between complexity and working time.

In particular, we deduct from the total capacity to do, the time dedicated to the refinement backlog, technical breakdown and sprint planning . This provides an incentive to make these meetings effective and removes the risk that these meetings may get long.

To estimate the complexity, we use an agile card game and we rely on benchmark tickets. We note each ticket and the sum of the notes of the tickets, to be made, must be close to the capacity to do of the team whose measure is refined sprint after sprint.

Each team member independently estimates the complexity of the tasks and presents the team with a card from the Agile game with a number on it. If there is no consensus on this estimate, extremes are expressed until consensus is reached.

This only works if the following elements are respected:

• the US is clear
• the technical team has read it
• the task is technically cut
• the complexity is low <5 which is equivalent if we allow ourselves a conversion to a working day

If we do not know how to estimate the complexity, we timebox the time spent on the task. Example:

A timeboxed ticket  :

At the end of a timebox, we have either:

• finished the ticket: bravo!
• solved the technical uncertainty: we create a new ticket that follows the same formalism
• failed: the timebox made it possible to avoid spending too much time on a subject with improbable results. As a result, a junior asks a senior for help, a senior addresses a colleague or challenges the ROI of the ticket and opens a discussion with the PO.

During poker planning, the team takes the tickets from the  product backlog  that have been prioritized by decreasing importance and estimates them in turn. The team stops estimating the tickets of the  product backlog  when the sum of the complexity points of the tickets inserted in the  sprint backlog  exceeds the average capacity to do of the team.

The team took care of the following two points when defining the scope of the sprint.

The dependency graph

A ticket dependency graph is produced which allows you to define in which order to perform the tickets.

The dependencies are such that the team theoretically cannot be blocked. If one feature blocks all the others, the sprint perimeter is modified to give the team leeway on parallel tasks and make the best use of its capacity to do.

Example of a dependency graph between tickets in a sprint:

The sprint goal

Once all the tickets have been evaluated and the scope of the sprint fixed, we define a sprint goal.

The sprint goal encompasses several tickets and constitutes the priority of the development team, it is a macro-US, an epic or even a complete course. This is the priority of the global sprint.

It must be elementary enough so that less than 50% of the capacity to do of the team can answer it, otherwise we would take the risk of unknowns and would not keep it.

During the sprint

The  daily stand-up

What has been done: the burndown chart

In the morning, the PO brings together the development team and everyone expresses themselves on what has been done. The dependency graph is used and completed tickets are crossed out.

The burndown chart  is re-edited and lets you know where the team stands in relation to its sprint goal:

• Are we early / late?
• Has a problem occurred?
• How to solve the problem ?

The rest of the things to do

Each member of the team then decides on what to do. The choice is free within the limits of what is imposed by the sprint backlog and the dependency graph, with priority placed on the sprint goal tickets  .

Each member also chooses tickets that they will be able to complete during the day. We try not to drag a ticket from one day to another which would induce undesirable effects:

• inability to test and validate at the end of the day
• daily stand-up less relevant because work in progress
• initiation of a drift leading to no longer favoring the completion of tasks

Daily email

A recap is sent to the entire team to keep abreast of the progress. As CEO, this recap is extremely appreciated. It is quality reporting that allows me to understand if there are any problems and to react accordingly. It is also a great decision support tool for the PO!

Validation and production

Each time a ticket is finalized by a developer, the developer makes sure to respect:

• acceptance tests
• The definition of done
• good development practices, in particular rules related to git flow

In addition to the acceptance tests already presented, the definition of done  brings together elements of general value.

The developer pulls a feature branch  thanks to now, a tool from Zeit.co

He performs a PR and verifies compliance with the following rules:

All you have to do is get a positive review, be up to date with your master 's degree  and pass the tests on our CI tool,  CircleCI (now Github Actions):

The developer then shares the address of the feature branch on their ticket, a slack notification is sent to the PO who tests. If the test is positive, the PR is merged and the feature goes directly into production 🙂

At Melba, a push on github  launches the tests with CircleCI :

• unit tests on the front with jest, on the back with phpUnit
• functional tests with cypress on the front and behat on the back
• AirBnb linter tests  on the front and a custom linter on the back

The application is deployed on a cloud server via an ansible script   and  the  SPA build  is done by  webpack  on a server hosted by Zeit.co.

Releasing very frequently assumes that:

• tickets and PRs are small
• the reading of PR is given priority before the advance of another ticket
• the  build and deploy process is automated

Reading  The Gold Mine  is very instructive on this process: all the added value of the team, at every stage of the development cycle in the broad sense (from sourcing to corrections in production ), is pulled as far as possible towards the end user. We keep a minimum stock of added value at the different stages of development:

• we define priorities with a calculation of ROI aligned with our strategic initiatives (see  our article on lean )
• we minimize the tickets whose specs are ready (the added value of our PO lies elsewhere)
• we do short sprints
• we advance on the tasks in priority 4
• we read the PR in priority 3
• we put in production in priority 2
• we fix the bugs in priority 1

Retro

Yay! the sprint goal has been reached and the sprint is over!

There are two goals in a sprint: the sprint goal and the completion of all sprint tasks. The sprint goal makes it possible to secure a less ambitious objective and to ensure that a gain is however acquired at the end of each sprint.

The demo

We demonstrate new features either in front of the whole team or during the feedback that precedes the schedule (to reduce the  overhead  due to meetings)

The demo is useful for synchronizing with team members who are not part of the product development process and contributes to the satisfaction of the development team members.

Problem solving

During the retro in particular, or at each daily, problems are raised.

Example:

• a US is not well drafted
• we started a sprint containing tickets with outdated dependencies (API not ready)
• we started a long ticket at the end of the day and the work could not be validated

Each of them goes through a troubleshooting procedure to prevent reoccurrence.

We borrowed from Théodo the following problem-solving framework with columns:

• Date and owner
• Problem encountered and quantified impact (1 problem max per person per day)
• Root cause (5 Why methodology)
• Action that corrects the identified cause and prevents it from recurring
• Date of action (ideally the same day)
• Expected result
• Scheduled check date
• Observed result
• Status (problem identified, action proposed when the problem is encountered, action challenged by the team at the next daily, problem resolved)

Conclusion

For 2 years, Melba tried the  scrum  without much success. We did not respect its spirit enough and we did not have prior expertise in the field.

This methodology is often disparaged:

• too stiff
• stand-up unnecessary
• no sensitivity to technical debt resolution
• atomic work unsuitable for architectural work
• coping

From having tested the scrum that does not work then to the scrum that works, I think these remarks are obvious when we lack experience but that they are not correct in absolute terms:

• the supposed rigidity becomes comfort as soon as the process turns on its own. What satisfaction to be able to know in advance what will be done and to see week after week that the objectives have been achieved! In addition, we can exceptionally allow entry-exit tickets to the extent that they do not substantially change the sprint.
• the stand-up is effectively useless if we work for a week on the same ticket and we are not helped by the burndown chart and the dependency graph. With these tools, we are succinct and we take action. We cross out the completed ticket and only talk about the problems if they exist.
• technical debt can be included in sprints. We do this regularly at Melba. The lack of sensitivity to technical debt puts the company at risk, it becomes a business issue as well.
• the development team is responsible for properly architecting the applications and sprint tasks can be dedicated to architectural work. These tasks can also be timeboxed; at the end of the timebox, we report it to the rest of the team who decides to allocate more time to it depending on the resolution of the uncertainty. There may be more time allocated to R&D and in this case the dedicated capacity to do may be removed from the sprint as is the case for anything that takes time (meetings, interviews, etc.)
• the scrum methodology makes it possible to constantly know the progress of the development team, in particular by guaranteeing high quality communication. Is it better to have an opaque system that lowers trust or complete transparency that leads to many small successes?