trophy case to display the iteration and release goals, and all the identified work required to implement the current backlog of business prioritized capabilities to be delivered.
Figure 1: Example of Information Radiator keeping the Release amp; Iteration Goals visible
Reflecting again on the first Agile Principle, "early and continuous deliver" implies short iteration cycles. In fact, iterations should be constrained to be as short as feasibly possible. Ten business days is optimal, and helps emphasize (and make visible) the amount of effort required to producethe most visible (highest priority) work. It's not unreasonable for a software engineerto estimate and commit to 10 days of effort. Contrast this with having to commit to a large program with all planning attempted up front.
Keeping iterations short works because feedback, always guided by release and iteration goals, constrains the system so that it converges to the solution in the most efficient way. Shorter sprints help bring sharp focus to prioritized work underway andilluminate effort required and business value created. Both of these quantities can be measured and displayed on the Information Radiator using the so-called Burn-down and Burn-up charts which together provide real status on effort remaining and business value delivered. [4]
Keep the Product Manager Engaged
For this article, quot;product managerquot; refers to the clientwho defines and assigns business value to the capabilities being developed by the Agile team. In Scrum, thisrole is known as the quot;product owner.quot; It is critical that the product manager be engaged directly with the Agile team, and practices described in this section help fully integrate the product manager with the Agile team.
A good practice to engage the product manager is to set up a quot;product backlog boardquot; in a highly visible place near his or her office. This gives the product manager a place to post big ideas and unfold high level stories as the priority grows. Creating this board jointly with the product manager gives the Agile team a great opportunity to teach the art of writing stories. It also provides a great brainstorming area for the product manager to play what-if games by visibly sorting the stories into priority order. The product backlog board ideally becomes the source of stories for iteration planning sessions.
Mary Poppendieck cautions against the product backlog becoming an overloadedqueue (waste due to waiting in Lean terms), and I agree. [5] The purpose of the product backlog should not be to blindly pile up work to be completed in the future. It is best viewed as a visioning area where the product manager can stage prioritized work ahead of the next iteration planning meeting.A best practice is to have "epics" (big ideas that break down into several stories) guide what is placed in the backlog, and only unfold the details when needed (see Figure 2).
Allowing the product manager to re-prioritize work ahead of the next iteration gives a real sense of the change tolerance built into the Agile approach, and reinforces that Agile teams can re-align as business needs change. Contrast this approach with the notorious change control process built into legacy engineering practices to slow the amount of change to original requirements.
Figure 2a:Example of a product manager's Product Backlog Board, prioritized left-to-right. Note that detailed stories appear at the left side of the board, staged for the next planning session, but only higher level stories are at the rightside of the board. This emphasizes just-in-time unfolding of story detail.
Figure 2b: Zoom-in of Product Backlog Board, showinghow Epics (white cards) guide thestory unfolding (yellow cards).
Poppendieck also raises a valid concern that the backlog
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
