Every good design has to start somewhere. In Agile that beginning comes from User Stories and the creation of a Backlog. Dean Leffingwell in his book “Agile Software Requirements: Lean Requirements Practices for Teams, Programs” describes a backlog as the sole source of work for the team. Meaning the team bases everything the need to accomplish off of the Backlog. Which also means that the Backlog is one of the first things that needs to be completed before any development can begin. With that said let’s explore where the Backlog begins.
When a team gets together they begin gathering ideas together for their Backlog. Many of their most important ideas are pulled together from User Stories. A User Story gets the developer in the mindset of the people who would be using the software. A very basic User story: “As a user of product X I would like to be able to quickly save my process by a keystroke”. This is turn would be placed on the Backlog to code in a simple keystroke, say F5, to save the current state of their program. This is a very simple example but as you can see it gets the designers in the head of a user which could be tremendously powerful.
Although backlogs are great they should not be held accountable as if they were the Ten Commandments. Dean Leffingwell explains that developers should not be held hostages to their backlog. He says, “If the backlog you have isn’t the one you need to meet the release objectives, ignore the sunk costs and flush it!” What this really is that a developer should follow their Backlog but if they have met their current objectives but still have a few items that haven’t been completed, let it go. The costs start mounting in trying to complete every single objective, especially if other more important items in the Backlog have taken longer than first thought.
A product Backlog is an organizing tool for developers to use to stay organized and focused on their goals. The Backlog is taken directly from User Stories and are executed during Sprints. Sprints are the development times of the product design cycle. Different Sprints would have different goal outcomes depending on the complexity and difficulty of the backlog. For a personal example I spoke with a designer of a popular text app on the IPad (name withheld for reasons). His most recent Sprint was focused on a single item in the Backlog. That was to fix the UI that was left inoperable by the update to IOS 6. His Sprint was not completed until the UI was completely back to normal.
Image courtesy of: http://www.redminebacklogs.net/en/usage-product-owner.html
Leffingwell, D. (2010). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.
Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.