ALMComplete: Agile Scrum - Scrum Kickoff and Product Backlog

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark.

While Agile has different "flavors", Scrum is one process for implementing Agile. This newsletter is one in a series of newsletters that will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases. Here are the prior newsletters in this series:

Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm

30 Day Sprints
Agile differs from standard Waterfall development in that development has a smaller timeframe with a smaller feature set. Agile Scrum implements releases every 30 days (called 30 day sprints). Upon completing a sprint, you can move the software to production (if production-ready) or move into another 30 day sprint to implement additional features.

Pragmatic Agile Development (PAD) and Agile Scrum It is important to note that the way we use Agile Scrum varies from a purist version of Scrum as we have made modifications to Agile Scrum to work well for our development environment. Our version of Scrum is called Pragmatic Agile Development (PAD) and differs from a more purist Scrum implementation in these ways:

Scrum Planning - In Scrum, planning for an upcoming sprint is accomplished in 1 day, in PAD the planning spans 1 week. This is because we write more detailed specifications than a purist Scrum does (see next bullet item).

User Stories vs. Specifications - In Scrum, requirements are written on index cards (called User Stories) and does not contain prototypes or detailed explanations of the feature set. In PAD, we spend time detailing the requirement specifications with prototypes to ensure that time is well spent on the feature, reducing rework.

30 Day Sprints - In Scrum, development is done in 30 calendar days. In PAD, development is done in 30 working days, skipping holidays. This provides us with more evenly distributed sprints.

Team Composition - In Scrum, developers are expected to perform all duties (analysis, design, coding, test case development, execution, and documentation). In PAD, developers help with analysis and design and perform all the coding. We have specialized team members (Software Quality Engineers) for test case development and specialized team members for documentation. We do this because our experience has shown that we need specialists in these areas.

The goal of software development is to deliver your software quickly and with high quality, so tweaking a methodology to meet your needs makes sense.

Product Backlog
As your existing clients request new features or as you come up with new features that make the product more marketable, these items are called the Product Backlog. In the PAD Scrum Planning week, you will set the goal for the sprint and prioritize product backlog items to determine which ones can fit within the sprint.

Scrum Kickoff and Planning Week
In the purest version of Scrum, you have only 1 planning day for the sprint and requirements are written on index cards (called User Stories). We believe this is not enough time or detail to deliver quality features, as we have shown that taking the time to fully detail the feature saves time once the client (or your internal team) receives the features, it takes less re-work. So you should devote a week to planning.

Each release (or sprint) will begin with a PAD Planning Week. The first day of the PAD Planning week will begin with defining the goal for the sprint and identifying features you wish to have in the release (from the product backlog), in priority order.

In the purest version of Scrum, releases are done in 30-day sprints. The 30 days are calendar days, so with holidays and weekends, this may equate to 19 to 23 working days. We have found that sprints are best implemented in 30 working day sprints (excluding holidays), as this provides more evenly distributed sprints. The 30-day sprint begins after the PAD Planning week concludes.

During the first day of the PAD Planning Week, each team member will identify the number of hours they can contribute to the sprint, allowing you to determine the maximum velocity for the sprint (velocity simply means the number of hours that can be worked in the sprint). By knowing the maximum velocity, you can determine what features will fit in the sprint. After the high level features are identified in the first day of PAD Planning, you will assign specific work order numbers to each high level feature and assign a set of work orders to each team member.

The team members will spend the week defining the detailed requirements for their assigned work orders. Note: Work Orders are simply a hard copy document of each functional specification.

User Interface Design Guidelines
Because you will have multiple team members creating requirements, it is critical for your team to define your user interface styles in a style guide and ensure all your team members adhere to those standards.

Decomposing Work Orders
Since sprints are limited to 30 working development days, you will be forced to make hard decisions about the features that can fit into the sprint. When you are assigned a work order for a feature of the sprint, you should decompose the feature into multiple work orders so that you can prioritize specific pieces of the feature.

For example, let’s assume that you are redesigning your user interface for a more pleasing look and feel, and the aesthetics are the most important issue for the sprint. You also would like the screens to be more user-friendly, so you have some issues you wish to address (like prompting to save changes when changes are made and they switch between tabs on the screen). In this case, you should decompose these into 2 separate work orders (one for the aesthetics and another for the tab switching). By doing this, it allows you to prioritize the tab switching lower than the aesthetics.

User Stories vs. Work Orders
As mentioned, we favor work orders over a user story. Here is an example of a user story written on an index card:

Here is an example of a work order, notice how much more detail is presented and how having a prototype of the item you are delivering reduces ambiguity of the feature: