Backlog Items Tricks and Tips

A friend and apparent reader of this blog sent an email asking some questions about user stories and Scrum. The issues he raises are commonly encountered by teams beginning their Scrum implementations and I think the answers to these issues will be of use to all. After getting his permission to use his email as a source for a blog post, I am going to answer him here.

Hi David,

We are starting to get in the mind set of Scrum and have been meeting daily with our business team flushing out personas and scenarios creating a backlog for the rewrite of our product suite. We hope to start our first iteration the first week of September.

An interesting question came up today and I wanted to get your input.

What happens when there is no persona… and for that matter, really not a great story either? Take a BizTalk process, where the end use never directly interacts with the system. They input orders into their system, a document is zipped over the wire, to ours, and it is processed and sent to another party… eventually they look back in their system and viola, their order was confirmed.

I guess the challenge is that these are huge processes, which may take months to implement? How do we break that down into doable ‘chunks’ which we can put in our backlog, lock into a sprint and perform metrics against? The term requirements document seems to keep coming up, which to me just seems like 20 pages of bullets points and doesn’t sit well. Any ideas?

Thanks up front!

Jarod

First of all, Jarod, congratulations. It sounds like you are off to a great start. You are already avoiding one of the most common anti-patterns I hear from people when talking about their first attempts at Scrum. Taking the time to flesh out a solid backlog before jumping into an iteration is essential for effective Scrum. It may sound silly, but teams often try to use Scrum for the first time without an adequate backlog because they can’t get the customer or customer representative to play ball. You are obviously taking the time to step wisely into the breach.

Backlog Items Aren’t Always User Stories

Although we often use a user story to represent work in our backlog, it turns out that Scrum does not prescribe user stories; rather Scrum refers to backlog items. User stories turn out to be a very convenient type of backlog item and bolstering your user stories with background personas makes the user story even more tangible.

In addition to user stories, there are other common types of backlog items we might add to our backlog. Examples of other reasonable backlog item types include constraints, features, actions, behaviors, bugs, and refactorings. Many types of deliverables can be represented as work items within a product or iteration backlog. These other backlog items as represented in the backlog should still conform to the INVEST principle we commonly associate with user stories.

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

The Language of Backlog Items

One reason user stories work so well as backlog items is their clarity of intent. Is is extremely easy to understand the deliverable described by the user story, particularly if we use recommended language to write the story. One recommended formula for expressing a user story is this one:

As a [TYPE OF USER OR CUSTOMER] I want [THIS FEATURE OR FUNCTIONALITY] so that [DESCRIBE THE VALUEI GET FROM WHAT I WANT].

Implemented in an example describing a feature of a medical office application:

As a physician I want to identify the medication to prescribe within 8 seconds so that I don’t waste a lot of time looking for the proper medication.

How would this work for the BizTalk scenario described above in which a BizTalk listener service reads XML files from a folder and maps them to another schema before writing them out to a destination folder?

As a an XML shipping order file, I want to be transformed to an XML invoice and written out to a new file location so that I can be used by someone else.

That didn’t work so well. A better way to express this backlog item might be to first identify the item type and in this case I would suggest this is a system action. So, let’s start by writing System Action at the top of our 3X5 card and then consider the following formula for expressing our intent.

When this happens: [DESCRIBE THE TRIGGER]

This happens: [DESCRIBE THE RESULT]

Like this:

When an XML shipping order file appears in a prescribed file folder, it is transformed to an XML invoice and written to a predetermined file location.

Assuming this work required to accomplish this work is larger than a few days worth, break it down into smaller actions. Doing this interactively enables us to represent quite elaborate algorithms and orchestrations as a series of System Action backlog items. This isn’t quite as effective in a non-deterministic system, but non-deterministic actions may almost always be bounded by deterministic states.

Note the work item does not mention implementation. There is nothing in here about BizTalk, maps, adapters, pipelines, orchestrations, or business rules. We are describing trigger/effect or input/output. Huge sub-trees of BizTalk orchestrations begin and end with deterministic states and may be described this way.

Although we have talked a lot about BizTalk, these techniques work well in any system in which work must be accomplished without an identifiable user. Similar circumstances exist in web service models, batch processing situations, data and content syndication domains, and plenty of others.

There should always be a customer outside of the implementation team, but often the customer doesn’t give 2 hoots how you accomplish the tasks. In these cases, representing work items with different types and different language makes sense.

A Final Note on Testing

Given that you are working on a BizTalk system and should be automating acceptance testing along with your unit tests, do yourself a favor and check out BizUnit. BizUnit is a testing framework that is useful beyond the domain of BizTalk but is particularly useful within it.

Technorati tags: Agile, BizTalk, User Story, Scrum, Backlog