A lightweight implementation of Agile

The Backlog

Any project, no matter its size is made up of a set of requirements, and managing those can become quite overwhelming. Several dozen functions, a whole committee of stakeholders and users and you will soon find yourself in over your head. Lucky for you, the backlog makes gathering and managing requirements simple: It is a strictly hierarchichal list of items sorted by priority. No two items can ever be equally important.

  • Strictly hierarchical list
  • Starting from the top and adding at the bottom ensures you complete the most important features first
  • Regularly reevaluate the top of the backlog to stay on track
  • Use the backlog to clearly communicate to your stakeholders what will be done and when (relative to other items)

Implementing the backlog can literally happen through post-its on a whiteboard or an excel sheet. More advanced implementations are the trello project management system or the Greenhopper plugin of the JIRA management system. In the spirit of lia, it is recommended to use the simplest, most lightweight tool and work your way up only if necessary. The backlog is maintained by the person responsible for the project, be it project manager, product manager or team manager. They have the last say regarding the priority and it is their job to make sure the requirements are properly handled.

User Story Format

To help both stakeholders and developers communicate about requirements in a common format, lia uses the User Story. It describes the requirement from the perspective of its respective end user. Using this format to describe the requirement instead of technical terms allows the client to actually sign off on the work to be done as well as check whether it has been completed. On the other hand, it does not limit the professional in the technical steps they take to implement the requirement. If there is a simpler, more efficient way to solve the requirement, he is free to take that route, as long as the requirement is met. A good User Story is characterised by following the INVEST formula by Bill Wake.

An example User Story: As the head of sales, I want to be asked to sign off on changes made to the client database so that I can intervene if I believe an account has been closed in error.

It follows the basic format of "As a -role- I want -requirement- so that -benefit-. This requirement is pretty clear on the business side. On the technical side, the developers can solve this requirement in a couple of different ways, for instance by creating a list that the client has to actively call up in the program or by giving them a pop-up on their tablet PC. They might even suggest not implementing the solution in this way, but instead make the application track all changes and make them reversible.

To make sure the technical solution takes into account the clients' business constraints, acceptance criteria may be added. One such criterium might be that in order to prevent abuse, every single sign-off requires a login with username and password. As with the user story itself, the purpose is to have a common understanding when all the criteria are met. If new criteria are discovered by the team, they may choose to add them to the existing ones and ask the client for an extended deadline or create an entirely new User Story.