The Tools of Transparency

Tool #1: Strategic Objectives

Before beginning any work to create a new product (such as a website) or improve an existing product, an executive should establish and communicate strategic objectives for the product. The strategic objectives for the product provide an outline or framework that guides all of the product’s features and requirements.

In an Agile process, the aggregated collection of all user stories for a particular product is called the Backlog. Each individual user story, and collectively the Backlog of user stories, should contribute in some way to the product’s strategic objectives. If user stories lose alignment with the product’s strategic objectives, either the user stories should be changed or the product’s strategic objectives should be changed. Keeping these components aligned improves the likelihood that the effort expended on a product will have the maximum intended business impact. If this alignment is not a focus area, Agile project teams may stray away from the original objectives to new objectives without communicating the change.

Executives will usually not be involved in the daily project mechanics, but Executives should use their interactions with the Agile project team to set the expectation that individual user stories and the collective Backlog of user stories must support the product’s strategic objectives. If the Agile process leads the team toward a new set of strategic objectives, executives should be open to hear proposals for changing the product objectives in a formal way. In this way, Agile allows both flexibility and consistency.

Tool #2: User Stories

As an Executive, you are unlikely to be directly concerned with writing user stories. Nonetheless, you need to understand how and why user stories are created, since they are basic unit of work in an Agile project.

A user story must provide value to some user. An Agile process is driven by the completion of stories, each of which provides tangible, demonstrable value to the user/customer/stakeholder. A sprint consists of a set of conscientiously prioritized stories. Experience will show that it’s best to use a format for each story that identifies who the user is, what they need, and for what purpose (the why). Such stories are written in this format:

“As a ____, I need a ____ in order to ____”.

The who in a user story could be someone with a particular functional role, who holds a certain title, comes from the perspective of a persona, or embodies the needs and behaviors of a hypothetical user.  The what in a user story details in specific terms the need, feature, or functionality desired by the who. This is what your project team will build into the product or service.  The why in a user story states the value. It presents the needs of your users and customers up front and center.  Here’s an example of a user story that clearly defines the who, what, and why: “As a jazz fan, I need a tuning knob in order to find a jazz station on the radio that I will enjoy listening to.”

Keys to a Valuable User Story

  • Product Owners must have courage to ask for what they believe their users/customers/stakeholders really want.
  • A story must have value to someone. It must make the product better in some way.
    • The story when complete will make a real-world task faster, better, easier to understand, have fewer steps, or collect better info.
    • The high priority stories affect the most users or procure the highest value data.
  • “Clean up the bugs we introduced in the last sprint” is NOT a user story because it does not add anything to the product.
  • Remember the INVEST model! Good user stories are:
    • Independent
    • Negotiable
    • Valuable
    • Estimable
    • Small
    • Testable

By making user stories Independent (producing workable features that can stand on their own), Program Managers are given the ability to make intelligent tradeoffs. This power translates into an advantage for you, the Executive, because it allows you to also make budgeting decisions without being beholden to artificial limitations. On an Agile project, you should never hear a subordinate say “We absolutely cannot release on that date,” because the software is always releasable — each iteration should be workable on its own, albeit with room for improvement.

Ensuring that user stories are Independent is the role of engineers and the writers of user stories. You should insist that your teams keep good backlogs of stories and that they follow the INVEST acronym rules. You may participate in writing user stories occasionally, although that will be rare.

Tool #3: The Storyboard

The Storyboard is a Big Visible Chart that is really the heart of the project. It must be where everyone can see it. A whiteboard with sticky notes works fantastically well for this. This is another tool that lends transparency to the project, so everyone can see what is being worked on. The highest priority stories, visually, are on the top of the list in each lane.

As an executive, you will not be working with the Storyboard as much as the Product Owner and Product Manager do. However, it is your job to make sure that each of your teams IS keeping an up-to-date Storyboard, using it as a tool for managing their work within the project and for producing accurate, usable Burndown Charts (described next).

The Product Owner can put a story into the backlog at any time. The PO and others on the customer-facing team should be constantly “refining” the Backlog for stories ready to be placed on the board, based on changing business needs or because they have been able to complete a story with enough detail to be worked on.

Here are some actual working boards:

Example Digital Storyboard

Example Physical Storyboard

Tool #4: The Burndown Chart

The progression of stories and their assigned points, as they move incrementally from Backlog to Done, can be expressed in a Burndown Chart, shown below. This is one of the tools that gives transparency to the progress in the project. Every day it is updated, and it lives in a high traffic area so anyone on the team can view it.

The Burndown Chart is based on estimates of how much effort each user story is expected to take. Estimates exist to serve you, the Executive. The purpose of keeping estimates is to allow good management decisions to be made. It is difficult to estimate how long it will take for work to be done on a project, particularly within a Sprint or time box. An estimate is a guess.

The example below shows a team working in a two week sprint cycle. Based on historical experience known as velocity, the team knows that it can complete roughly 45 Story Points worth of work each sprint. Working with the product owner, they identified a mix of high priority user stories that added up to 45 points as represented by the yellow line. From the 45 point mark, a red line is drawn to last day of the sprint which produces an ideal burndown trend. Most teams will fluctuate above and below this line throughout the sprint. As the sprint progresses, user stories are completed and are represented by the blue line.

BurndownChartExample1

Back to Lesson 2