Magic Backlog Patterns

Agile development processes are driven from a backlog of development items. This paper describes patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. The need to formalize the backlog increases with the size of the project.

Agile development processes are driven from a backlog of development items. This paper adds three new patterns to our collection of patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. The Funnel adds new content to the backlog, the Pipeline prepares backlog contents for implementation, and Maintenance performs continued care of backlog contents. The need to formalize the backlog increases with the size of the project.

Agile development processes are driven from a backlog of development items. This paper looks at how to apply patterns from our Magic Backlog collection through the use of storytelling. We follow a project through various scenarios from the early days through significant growth into a mature setting and then, finally to a disruptive transition as the project becomes part of a program. Our goal is to focus on common project issues that we believe are experienced by many people involved in software development, and how the use of combinations of patterns, including our own as well as other patterns and practices, can help resolve or mitigate these problems.

This paper extends our Magic Backlog Patterns collection with three additional patterns for managing the work of a program– or rather how to deal with coordinating the work of projects which are part of a larger program and where there may be dependencies and shared deployment. While teams within a program may work fairly independently, their work still needs to be coordinated to produce a product. These three patterns, which represent alternative strategies for structuring the backlog of work, are introduced through a story of the correspondence of a business analyst as her hypothetical program moves through different backlog management strategies.

Agile development processes are driven from a product backlog of development items. This paper adds three more patterns to our Magic Backlog collection of patterns to build and structure the backlog for an agile development effort using the outcomes of requirements elicitation and analysis. RULES defines who should be allowed to do what in managing the backlog, SHARED DEFINITIONS deals with defining and consistently using clear criteria for core decisions across the backlog team(s), and REMODEL is about restructuring the overall backlog contents.

As patterns authors, we spend a lot of time writing. Usually our work is driven by what we want to share of experiences, working solutions, and ideas we are excited about. But how often do we think about the readers other than initially stating our intended audience? Who is going to consume our writing, and are we really putting in the effort to reach these readers in the best way possible?

This paper started because we are two authors who plan to make a book from a set of related patterns papers, and in doing so we really want to reach our target audience and provide a practical and useful piece of work. Our approach had two distinct investigation activities. One was to do an informal analysis of books about software processes and methods to gain a better understanding of characteristics and book design practices for this kind of book. The second was to use a combination of interviews and surveys to gather feedback on what readers are looking for when accessing information about software engineering. To better understand our potential readers and how to design our writing for their consumption, we created personas where we incorporated feedback from the reader survey into their personalities and preferences. Finally, we combined our information sources to create guidance for our future work of turning a set of patterns papers into a cohesive whole.

This is an about paper—one that we write to gain a better understanding, for ourselves and our readers alike, of the usefulness of a pattern language and what it takes for experience captured in pattern form to be of use to others. In it we look at what it means for individual patterns and collections to be generative and explore some differences between those that are highly generative and those that are not. We ask whether software design and software process patterns can be generative and, if so, what is their potential impact. Finally, we draw some conclusions on how these thoughts on pattern generativity could influence future writing of and support for generative patterns.