Fear the Walking Devs

Posted in: Back-end development

Intro

Picture the scene. You find yourself in a room with a handful of fellow human beings, waiting. You’ve all been through this before and you’ll go through it all again many more times - if you’re lucky. The other side of a sturdy metal door is a collection of zombies. Your task: as a team, sprint to the next safe house, dispatching as many of the monsters as you can.

Welcome to a journey through Pivotal… with zombies!

What’s a Pivotal?

Pivotal Tracker is the application we use in Digital to track the work we do through our two-week sprint cycles. As new work requests come in they are added to the icebox as new user stories, along with any special requirements or notes. These stories are regularly reviewed and those which are to be worked on as a priority are moved into the backlog, ready for the developers and designers to tackle.

With the backlog fully stocked for the sprint ahead, the stories are picked up one by one and worked on. Each story will go through a series of states before it can go live. Essentially these are:

  • Started: The story is being worked on
  • Finished: The story is complete and can now be peer-reviewed
  • Delivered: The story has now been reviewed and the Product Owner can give it a final check before accepting or rejecting it.
  • Accepted: The story meets the requirements and may now be shipped.
  • Rejected: The story does not meet the requirements, meaning it will need to be restarted and go through the states again.

Thankfully, we see a lot more accepted stories than rejected ones due to our fairly in-depth review process.

But, back to zombies…

Pivotal is a city under siege. A zombie outbreak has occurred and it falls to a small group to try and sprint from safe house to safe house, clearing a path through the monsters as they go. Each survivor has their own role to play and no two zombies are alike. The survivors won’t stop until Pivotal is once again free of the outbreak, but their task is by no means simple.

The brave survivors

Every zombie story needs its collection of survivors – a group with varying skills working together to survive the horde. Our group of survivors has three classes:

  • The Developer / Designer: This class is the plucky survivor with a shovel or other improvised weaponry. In our case, the weapons of choice tend to be a mouse and keyboard. They tackle stories which have been selected by the Product Owner.
  • The Reviewer: This class is the ex-military survivor who has seen this all before. They take code from the developers/designers to ensure that it works, it complies with our standards and conventions and that it fulfils the criteria of the original story.
  • The Product Owner: This class is the tactician of the group, deciding which stories to target and having the final say on whether the implementations provided by the developers meet the requirements. They tend not to enter the fray directly, but will provide tactical advice and guidance to those who do.

With their roles assigned, our intrepid group grabs the nearest weapon and prepares to face…

The horde

The horde is the contents of the Backlog and Icebox. Our survivors can tackle the stories as best they can, but there always seems to be more to replenish their numbers! Our horde consists of the following classes:

  • The Story: The generic zombie class. There are many of them and they come in all shapes and sizes. Susceptible to building new features.
  • Bug: The stealth class. They like to hide in the code and surprise passers-by. They aren’t worth any points, but eliminating them will make life easier for the other survivors.
  • Chore: The tank class. Easy enough to avoid, but our plucky survivors will only have to encounter it further down the line. Eliminating them is often the first step to clearing out a nest of nearby stories. There is a subtype of the Chore known as a Discovery. This is a special class which rewards the survivors with knowledge when they are dispatched. They are always worth three points.

Within the horde, members of the Story class can vary in size. They are estimated by the survivors before they are encountered. They are judged on their complexity and are rated based on the Fibonacci sequence – the bigger they are, the more points are assigned, up to a maximum of eight. Before the sprint hits, the Product Owner will advise how many points of stories the survivors can tackle in the encounter.

The safe house

After sprinting for what feels like two weeks, our survivors reach the next safe house. From here, they have a retrospective on what just happened, allowing them to reflect on their successes and what could be improved in the future. After taking a brief rest, they plan the sprint to the next safe house – with the Product Owner determining the path they will take, and which stories need to be dealt with on the way.

Then, as before, our survivors tool up, take a deep breath and begin to sprint once again.

Posted in: Back-end development

Respond

  • (we won't publish this)

Write a response