Plan incremental software releases in system spans

To get the value out of our software, it will eventually need to be put into use. Well sort of. If you're creating and selling shrink-wrap software you'll get your money when customers buy the software. But we'll assume that they buy it because they intend to use it, and if it doesn't work well, word will get out and not many will buy it, and those that do may want their money back - or at least start complaining that the software needs additions and changes before they can use it.

But there's a common problem that occurs when planning for the release of software, particularly new products. The software we need to build is ultimately a collection of features. It seems a simple idea to prioritize the list of features and choose the highest value features for a release. However, features are built to support the work practice of the target users of the software. While a software release may include many high value features, the software won't be used unless the target users of the software can incorporate it into their work practice. This may ultimately mean those who paid for the software won't get their return on investment.

Planning a software release to support use can be difficult. There may be a large number of tasks users engage in to meet their goals. Tasks generally depend on each other where one task must be or is often completed before another task. A release that didn't support both dependent tasks wouldn't be usable.

While the ability to complete some tasks is a necessity, other tasks may provide optional flexibility to our users. Still others may provide desirable efficiencies or luxuries to our user. Including a luxury while inadvertently excluding a necessity can result in a software release that may be desirable to purchase because of the luxury, but not feasible to use because of the missing necessity.

Finally, software targeted to support many users and the business process they're engaging in must take into consideration the entire span of that business process.

Working through all these task considerations and dependencies to plan the successful release of software can be difficult. A span plan is a simple spatial user task modeling technique that takes into account the entire span of the business and the necessity of a task in that business process.

A span plan is a simple 2D model where user tasks are arranged left to right based on performance dependency where tasks happening early in a process fall to the left of tasks happening later in the process. These same tasks are then arranged top to bottom by necessity where tasks at the top are necessary to the business process, and tasks below the top axis add optional flexibility, safety, comfort, performance, or luxury to the business process. Use feature thinning guidelines to help identify optional tasks and to better understand how optional they are.

Vertical swim-lanes separate breaks in activities where tasks in one swim lane make up a coherent activity usually performed by a single user constituency.

Arranging tasks left to right across all user constituencies and activities results in a model that takes into account the entire span of the business process. Slicing such a model left to right results in coherent releases that take into consideration business process span, workflow, and task necessity.

A Span Plan is constructed like the model above where each pink box represents an index card or sticky note containing a user task. The shaded area at the top of the model marks the smallest necessary set of tasks that must be implemented to support all activities in the business process.

Before attempting to build a Span Plan, you'll need an understanding of the user constituencies of your software. This understanding is well represented in some type of user model. While the user model may give you an idea of your users' goals and the activities they engage in to meet their goals, you'll need a good list of user tasks these users perform while engaged in activities to meet their goals. Building a user task model is the best way to obtain such a list.

To help determine which user tasks might be necessary to support in your software, leverage a business goal model that indicates clearly what your business objectives are. To map out specific releases you may need to consider specific release level business goals.

Construct the span plan in a collaborative modeling session. These step by step instructions will give basic directions on hosting a collaborative modeling session to construct a span plan. If you read the instructions for creating a user task model, you will probably find some similarities here.

Prepare

Identify Scope and Goals

Consider constraining the scope of this activity to a specific business process. This usually implies specific user constituencies and specific activities they engage in to support that business process. This will help constrain the size of the span plan you'll end up building. Leverage a business goal model to help identify the business process to target with the software. If you'll be adding functionality or changing functionality in an existing software product, indicate that product as part of statements you make regarding scope.

The goal of this sort of session may simply be to build the span plan. Or, you may continue through to high level estimation of features to support user tasks in the span plan. You may further continue on to marking out specific releases on the span plan. Choose a goal for the specific session that indicates this stopping point.

Write a concise statement that summarizes the scope and goal to use as part of the invitation for the meeting, and to aid in kickoff for the meeting.

A good scope and goal statement for a software company developing additions to their point of sale software might read:

Identify Participants

Find information suppliers that are familiar with the business process you'll be discussion based on the scope and goals of the session.

Include business stakeholders familiar with the business goals for release of this product. Even if the goals of this particular modeling session don't include creating a release plan, it's important they're present as information acquirers. What they learn while modeling will help them make better release decisions.

Include members of the design and development team. I like to include at least a lead developer and a lead tester. They will help model and acquire valuable information that help them make later detail decisions during the design and development process.

Prepare Data

You'll need to leverage your user model, task model, and business goal model. Information suppliers should bring these models and be prepared to speak about them.

To create the span plan, you'll need the user tasks that support the business process in scope written on index cards or sticky notes. If you have user tasks in an electronic form, use mail merge to print the tasks on paper that can be cut down into cards for modeling; or print directly onto pre-perforated index cards. Make sure that each printed task card contains the task name and the task number that identifies the task. It's helpful to include the activity name the task falls in. You may choose to include other attributes of the task that you captured during task modeling.

To create a span plan, I like to use pre-perforated business cards. When you use large type to print the task name, they're just big enough to read easily, and you can get a lot of them printed on a single sheet.

Gather Supplies

Just in case, bring your collaboration supplies. You'll likely run through additional index cards and lots of cello tape to stick them down to the model. You'll need poster paper to fix the model to when it's done, and to create a parking lot and feed forward bins. You'll need a camera to shoot a model photo and ideally a model movie.

Schedule

The time you'll need will depend on the scope and goals of the span plan to be built. A single 1½ hour session is ideal. If you believe your span plan will be very large, schedule two sessions with a break in between. Make sure you leave 15 minutes or so to wrap up the session.

Create a Span Plan

Start the meeting by reviewing the scope and goal statement for the meeting. Make sure everyone knows each other, in particular make sure everyone knows who the information suppliers are, and what knowledge they bring to this activity. Point out the posted parking lot, and any feed forward bins you've hung.

Using just a couple minutes review the business goals of the software you're beginning to plan for.

Review the business process that will be the theme for this span plan.

If participants are unfamiliar with some of the concepts you'll be using in the span plan such as user tasks or activities, consider briefly discussing those concepts. But, you'll find that people pick up fairly quickly given the examples of tasks you've brought to the session.

Standup, shake out, and get ready. You'll be active for a while.

Set up your modeling space

I prefer to model on a tabletop. Some prefer using a wall. Either way, spread out enough poster paper to hold the model. This is a long, wide model. Depending on the size of your business process it could be a couple yards/meters or it could wrap its way around the entire room. If it does the latter, consider reducing scope.

Once paper is hung, draw a horizontal line near the top and all the way across the modeling surface. Label the line "time."

Draw a line on the left edge of the model. Label it "necessity."

Identify and order activities in the business process

The business process you've chosen to model will likely be composed of high level activities your user constituencies engage in during the business process. Write the names of each of these activities onto index cards and place them across the top of the model above the line marked time in the order they occur when describing the business process. I usually use blue cards.

Be prepared to move these activity cards around. If you're modeling on the wall use sticky notes or removable double stick tape on index cards.

Let's use a simple retail sales business process as an example. I hope everyone's purchased something at a retail store before so you can easily imagine how this works. People working in a retail environment might engage in the following activities:

1. Purchasing items to stock in the store
2. Receiving items for sale in the store
3. Selling items at point of sale
4. Analyzing sales to make reorder and return recommendations
5. Returning defective or customer returned merchandise back to the vendor

You can probably guess that each one of these activities has a number of smaller bits of work, or user tasks, that make them up. Activities organize a number of tasks users perform when engaged in the activity.

You might also notice that I placed them in what seemed like a logical order. But, really it's not the order they're performed in since it's likely someone is in the back room purchasing items to stock while others may be out front at the same time selling items at point of sale. Really all these activities may be happening all at once. But if I had to tell someone how a retail business process works, this might be the order I'd tell the story in.

My model might start to look like this.

The placement of the blue activity cards doesn't matter too much yet. As we add in tasks, they'll move around.

Place tasks into activity in task order

Moving activity by activity, place the task cards you've pre-printed or pre-written in a pile under the activity. In this example I indicated pink cards for these task cards.

Then, moving pile by pile, arrange the tasks in the order they generally occur when a person engages in this activity.

For some pieces of software, arranging tasks in chronological order may be difficult. Consider the tasks you'd use in support of a very flexible tool like a word process or spreadsheet. There are a huge number of tasks that might be done in any order. Just like setting the order of activities previously, choose an order that reflects how you might describe the tasks in the activity to someone else. The act of telling a story about a user engaged in this activity is much like writing a user scenario. In fact, it may make things go smoother to write a user scenario, so do that if arranging tasks in order proves to be difficult.

For many pieces of business software, there's often a typical workflow that's followed, so often this process can go fairly smoothly. Be thankful if you're working on software like that.

Let's consider our retail business process. And, let's look a little closer at the activity labeled "selling items at point of sale." A simple set of tasks for that activity might be ordered like this:

1. Greet the customer
2. Identify the customer to the point of sale system
3. Add items to the point of sale transaction
4. Remove items from the point of sale transaction
5. Tell customer the price for the sale and ask for payment
6. Indicate payment type and amount to point of sale system
7. Accept payment
8. Print and give a receipt to the customer

If you're familiar with retail sales, you might notice I left out some stuff. You're right, and you might have many more tasks. But let's keep this example simple.

You might also notice that some of these tasks a piece of software likely can't help me with. For example "greet the customer." That's clearly something our user, someone performing a cashier role, needs to perform.

But wait… what if the customer swiped some sort of preferred customer card that identified him to the system? Then the cashier could know exactly who they were greeting. But, now I've dropped out of modeling and moved to design mode. I'll place that in my "cool product ideas" feed forward bin.

Looking closer at the "selling items at point of sale" activity, my model might look something like this.

Don't be too cautious about the exact placement of the cards just yet; they'll be moving around shortly. Just make sure to get them in the right order.

Identify manual tasks and out of scope tasks

You'll notice that some of the tasks are manual steps - actions our user takes that may not involve interaction with the software we're writing. Some of these steps may be also be handled or aided by other software that already exists. We want to treat these tasks differently, and we've got a couple of options. There's no right way to do this. Let the team choose their strategy.

To clearly indicate the step is performed, but won't be something we choose to automate in the software we're planning, change the color of the card or otherwise clearly mark the stop as a manual step. I like changing to white cards for this.

Another strategy is to remove them from the model outright. In many cases the steps just may not be interesting or are just noise in our model. If we remove a step we may choose to place a note on a preceding or subsequent step describing the manual step before or after. Write the note directly on the task card you choose to associate it with, or use a sticky note to fix it to the task card.

For example in our point of sale transaction there's a step to "accept payment." This is the pretty critical step where the person at the point of sale device takes a credit card, check, or cash from the customer and swipes it or puts cash in the cash drawer and makes change. If this doesn't happen, and the software we build doesn't make allowance for this manual step, the organization paying for the software will be pretty unhappy.

So in summary, tasks that are manual or not in scope for the software we're considering building change the color of the task card in the model, remove the task card outright, or replace the task card with an explanatory note fixed to the preceding or following task.

For our model, we'll change the manual tasks to white.

Arrange tasks vertically by optionality

When we look across the tasks we perform in an activity, some of those tasks happen all the time, some occur once in a while, and some seldom occur. If the task must happen during the activity, leave the card on the top row. All tasks on the top row are considered necessities. If the task might optionally happen move it down below the top row. If it seldom happens move it far below the top row.

Necessary is an interesting word.

Let's look at an example. Is a fire extinguisher a necessary item? It might be a feature of our kitchen that supports a task called "put out cooking fire." That task might fall inside a bigger activity called "cooking meals." Now, when flames are shooting toward the ceiling from my out of control sauce, that "putting out kitchen fire" task seems like a necessity. But, I personally have never had a kitchen fire (knock on wood) and while I remember getting an extinguisher once because it was necessary to my acquiring home owners insurance, I'm not sure I could now find it without a half hour search. By which time my saucy fire would have taken down most of my house. So, while "cooking meals" I've never done that task. What I'm getting at here is that necessity is contextual.

When building this model we're going to use a different definition of necessity:

In the typical situation where I'm engaged in cooking a meal, I don't have a kitchen fire. So, "put out kitchen fire" isn't a task that must happen for me to consider my meal cooking activity successful. Again, I'm talking about typical here. In the atypical situation where the kitchen was on fire, I'd tell a different story.

Let's look at our point of sale tasks.

The first manual task "greet the customer" isn't really necessary. It's nice, and our cashier should do it, but if there was a long line, I'd forgive them for not doing it. Let's move it down below the necessary row.

The second task, "identify the customer for the point of sale system" is because we know in our retail world we keep track of sales by customer. If we know who you are, it helps with processing returns later. It also helps us market to you. But, again if things are moving briskly, and this was a quick cash purchase, I could not tell the POS system who the customer was and it would consider the sale an anonymous cash sale. I'll move this task off the necessary line as well.

You might notice that I'm starting to discuss a lot about the specific business domain this point of sale system will be placed in. You'll notice this kind of discussion happens during modeling. If discussions like this happen and important details emerge, consider noting them directly on task cards or using sticky notes fixed to the task cards. Some folks choose to write these additional notes directly on additional "information" cards, and stick them directly in the model under the task card they're relevant to.

Let's look at our next task: "add items to point of sale transaction." I think this one is necessary. I wouldn't consider "selling items at point of sale" successful unless I actually sold at least one item. I'll leave this pinned to the top.

After stepping through each of our tasks, our model might look like this:

Notice that the "remove items from pos transaction" is moved fairly low in the model. This is a task that happens less often, and is less necessary in the typical "selling items at point of sale" activity.

Stack cards vertically to indicate concurrency

The left to right axis of our model indicates time. A task to the left of a task should happen before a task to its right. This isn't always true, just typically true.

You may find that as you've moved tasks up and down the necessity axis, you've made holes on the top row. This may allow you to more accurately represent concurrency by shuffling less necessary tasks under more necessary tasks that might in practice happen at the same time.

Relocate tasks that happen concurrently so that they share a column in the span plan.

Let's look at our "selling items at point of sale" activity. A typical cashier might be adding multiple items to a transaction. If an item is inadvertently added twice or our customer decides they don't want the item, that item must be removed. So during this time period lots of items may be added or removed. The "remove items from point of sale transaction" task could be considered as something that happens concurrently with the "adding items to point of sale transaction." Let's rearrange our model to reflect that.

Test the span plan by telling stories

Now we're beginning to have a model that lets us reconstruct a typical activity, and all the activities that make up a business process. We can test the model by stepping across it telling stories, or building examples of a typical activity.

Start your story by choosing an activity, and choosing a typical person that might carry out that activity. This is the hero of our story, our main character.

Then start telling the story by choosing a task on the left edge of the activity. Start with a sentence that describes our hero performing that first task.

Now we have a choice for the next part of the story. We can either step up or down the model in the same "concurrency column" to describe the next task in our story, or step right to describe the next dependent task.

Continue moving up, down, and right as you tell the story.

When moving right I find it helpful to prefix a task with "and then" to indicate dependence.

When moving up and down I find it helpful to prefix a task with "usually," "optionally", "sometimes" or "once in a while."

Let's tell a story using our "selling items at point of sale" activity. I'll choose a cashier as our user type.

This type of story is a simple user scenario. It's not really concrete since I indicated steps to be performed optionally and sometimes. I haven't chosen a name for our anonymous cashier, our customer, or a specific type of payment. Making all those things literal would move our abstract scenario toward one that was more concrete.

By speaking this sort of simple scenario out loud in our collaborative group, we've helped validate the tasks in a typical activity, and their order. While verbalizing these scenarios we may detect tasks out of order or missing tasks. Move tasks and add tasks to the span plan as necessary.

Add other annotation to the tasks or activities

While telling stories you may unearth interesting details. Write those on sticky notes and fix them to the model. Or, write them directly on task cards or directly on the poster paper that backs the model.

Add activity details

Interesting details you could note near the name of the activity might be:

• The types of user constituencies engaged in that activity, including direct users of our software, and other people involved in the activity
• The location the activity takes place in
• Any interesting details about how fast or slow the activity is performed

Add task details

Your task cards may already be annotated with some details. As you tell stories, other interesting details might emerge such as:

• How many times a task is typically repeated during an activity - for example 5-10 items are typically added to a point of sale transaction or there are 100 moves in a typical chess game
• Details about the external environment that might affect the task - to print a receipt we must have receipt tape

Add Feature ideas

As you think about the activities people engage in, and the tasks they're performing, members of you group likely won't be able to stop from thinking about possible product features that could help your users complete their tasks. Write feature suggestions on sticky notes and fix them to the model near the task or activity they're relevant to.

Use the surface of the model to trap details relevant to understanding the work of people engaged in these tasks.

One warning: this sort of annotation can, at times, go a bit too far. The primary goal of the span plan is to illuminate activities, tasks and their dependencies to support planning the best possible software release. If ad hoc annotation begins to clutter the model such that that basic workflow isn't clear, consider annotating less. Or, annotate on sticky notes so the annotation can be removed at a later time and recorded elsewhere.

Take a breather

At this point you've built a span plan starting with the activities and tasks you initially understood. You may have added, removed, or changed tasks. You may have annotated tasks and activities with additional details that came up while modeling and validating the span plan model.

You now understand the typical sequence of activities and sequence of tasks in the activities that make up your business process. The top row of your model in particular indicates all the necessary tasks that must be supported in a piece of software to demonstrate the end-to-end business span.

Stand up and stretch.

The modeling session could stop here to be reconvened later to begin a task thinning and release planning activity. If you choose to stop and reconvene sometime later, close the meeting, then document and communicate the results. At a later time reconvene work sessions to plan your product releases.

Plan product releases

Planning a release requires juggling a few concerns all at once. Imagine a juggler in your mind. Our juggler is juggling three balls with these labels: Users, Business, and Development.

Juggling user concerns

For the users of the software you ultimately release, the software needs to fit well into their work practice. It must support all the necessary tasks they engage in during their work practice. Or if it doesn't there'd better be some easy ways for them to work around missing features.

Juggling business concerns

For the business paying for this software, they'll need to release the software and begin to earn revenue on it as soon as possible. The money they're shelling out to build this stuff should ultimately earn a return that's competitive in the market. The business only gets value from the software when it's in the hands of its users.

There's also value in getting software released to validate issues like usability and scalability. While an early release may not go to all end users, leveraging it to validate these things can substantially reduce risk.

Juggling development concerns

Planning releases without a clear idea of exactly what will ultimately be built can be a bit nerve-racking. Those designing and developing the software to meet both user and business needs need enough detail to estimate roughly how long their design, development, and validation of the release might take.

Now, let's think about our juggler again. A juggle can't pay too much attention to any one ball and keep them all in the air. A juggle can't hold on to one ball long before tossing it back up and dealing with the next.

While you plan product releases you'll be juggling these three concerns. Don't pay undue attention to any one concern. Don't focus too long on any one concern without considering impact on the others.

While planning a release your team will follow a loop of steps something like these:

1. Estimate development based on assumed feature ideas and complexity
2. Slice out releases to ideally meet end user needs
3. Identify release dates based on development estimates and ideal business release cycles
4. Thin tasks or make thinning assumptions about features that support the users tasks
5. Go to step one and begin again.

Estimate development time

With an existing span plan your team can see the tasks users need to engage in across many types of users and activities. If your team has built this type of software before, they may be able to imagine how software that supports these tasks might look and behave. At this point they may be able to give very rough estimates on how much time it might take to design and develop features that will help users complete their task.

Developer should quickly and collaboratively estimate time to develop features that support each task. Use collaborative approaches such as those described by Mike Cohn in Agile Estimating & Planning. Consider characteristics from feature thinning guidelines such as flexibility, safety, comfort, performance, and luxury. Where a task might require a high amount of any of those things, developers may consider higher estimates. Discussions about these characteristics involve both developers and information suppliers in the collaborative meeting who understand the users of the application and their use as well as the business goals that make one user and their work more important than another.

I find that at this level the team can't estimate in hours or days, but is best to estimate in weeks. There's often not enough detail to warrant estimating at any finer level.

If estimation is difficult because there's just too much uncertainty you may not be able to proceed. Continue to mark releases that best meet user needs, then:

• Write user scenarios for important paths through the business process
• Create low fidelity user interface prototypes to envision the software and features that support those user scenarios

Reconvene another collaborative work session to estimate and plan leveraging these user scenarios and low-fi prototypes to help make the feature solutions being estimated more clear.

Slice out releases that meet user needs

The span plan is optimized to support slicing left to right. The higher the slice, the more necessary the task is to support. Slicing the entire model left to right ensures the entire business process is supported. You need only choose how deeply to slice. But, that's often not an easy choice to make.

At this point in a collaborative work session those most familiar with the users and their work should choose a level of depth for a first release that allows users to comfortably use a resulting product.

Draw a line on the model (I'd suggest using pencil), that cuts across the model left to right.

This isn't a straight line. It'll likely cut up and down to take in some tasks and exclude others. That's OK. If you find the line dips up or down substantially, discuss why. Are the tasks positioned with a low necessity that should be positioned higher? Is the opposite true? Are some tasks being supported not because they're necessary for users, but necessary to be considered competitive to other products in the marketplace?

The first line is the hardest. You've sliced away a first release. Now continue to look down the model for other sets of tasks to support which package features together that could comprise valuable subsequent releases for the product.

Identify a release date for each release

For each release you've sliced away, there are two candidate release dates.

Identify the ideal release date

The first release date may be based on what's ideal for the business paying for the software. When would it be ideal to deliver this functionality to users to meet opportunities in the market or begin delivering return based on the use of this new tool?

Write this ideal business release date down on a sticky note and fix it to the model.

Identify the estimated release date

The next release date is calculated by adding up the development time estimates. Add these estimates up. Multiply them by any factor your company uses to incorporate design time, testing time, risk, or uncertainty. Every company seems to have a factor somewhere between 2 and 4. I use pi. If your company doesn't have one, you're either fabulous at estimating or foolish; and you won't be able to determine which you are, so don't fret about it too much. Divide this estimate by your team size. Using this calculation determine when the release is likely to come out based on development estimates.

This isn't a book about estimation and planning. But I'll leave you with just a little advice. Large teams add drag to development. If you have a team size larger than 10, increase the multiplier you applied to your estimates.

Discuss how to deal with the difference

Given these two dates, one ideal for users and market conditions, and one based on the time to develop the product, there will likely be a difference.

If your ideal release date is later than your estimated release date, celebrate, and send your team out to buy lottery tickets. You're lucky people. Also consider adding support for more tasks into the release. Also consider increasing the estimate assigned to some tasks. This increases the budget available for features that support users engaged in this task. A higher budget may mean greater flexibility, safety, comfort, performance, or luxury.

It's likely your ideal release date falls earlier than your estimated release date. You've got a few choices here.

1. Reconsider where you've drawn lines to slice the span plan. Consider excluding some features along the border.
2. Reconsider assumptions you might have made while estimating what could cause estimates to be high. Consider scaling back your assumptions about complexity, safety, comfort, performance, & luxury.
3. Thin tasks using feature thinning guidelines. Thinning now at the task level implies we may look a little harder at tasks and identify steps of tasks - tasks within these tasks that can be pulled out, and made more optional. The result of this activity adds more tasks to your model and fattens it vertically from top to bottom. Given your fattened model, reconsider your estimates, the slice you've made for each release, and identify again ideal and estimated release dates.

You might also consider a mixture of all of these strategies. Adjust release slice, adjust estimates, and thin a few of the tasks in the model.

This is a busy collaborative process that involves developers who are familiar with how they might design and build this functionality, information suppliers familiar with the users and their work flow and interaction designers or others that can envision how the software might look and behave.

Fatten the model by thinning the tasks

Tasks describe the physical actions people take while trying to meet their goals. The steps inside those tasks are themselves tasks at a lower goal level. If we find ourselves in a place where we'd like our later estimated release date to move closer to our earlier ideal release date, thinning is a good way to accomplish that.

Using feature thinning guidelines we can classify the characteristics of a features as necessary, or as characteristics that add additional flexibility, safety, comfort, performance, or luxury. While we can't remove necessary task support from our system, we could consider removing a task that simply adds flexibility or increases performance.

Demote the necessity of tasks in your span plan

You might fatten your model and cause tasks to jump from one release to another by reconsidering how necessary a task is considered. This may allow earlier releases to be designed and built in less time.

If the task is pinned to the top of the model where the necessities are placed, is it really a necessity? Can you consider a way that your user could succeed in the activity without performing this task? Could your user perform this task using a tool other than a feature in your software?

If the task is not already a necessity, reconsider how likely it is the task will be performed. If you've annotated tasks with task frequency information, that may be helpful here. Also consider how valuable this task is both to the user who performs it, and the business paying for the software. Is the importance of the task overstated? If so, demote it to a lower vertical position on your span plan.

Divide tasks in your span plan

Dividing tasks adds more cards to your span plan, but allows you to distribute the time it takes to build features that support tasks to different releases.

To divide tasks already on your span plan, choose a task that you might consider a candidate for dividing. For that task discuss out loud, or even better write down the steps for that task. For each step ask the question is this step a necessity? Or does it add flexibility, safety, etc. If there is a task inside a larger task that can easily be classified as less necessary, write it down on an index card and place it in the model somewhere below the task it was split from. It falls directly below that task because, as a sub-task, it will be performed during the same timeframe as the task it was pulled from. And, it will likely appear lower in the span plan since we've identified and extracted it as a less necessary task than the task it came from. Then rewrite the task name that you extracted tasks from to make it more explicitly exclude the tasks you extracted.

Let's look back to out point of sale software for an example.

Let's look specifically at the task: "add items to a point of sale transaction."

There's not a lot of information here. I can imagine someone in a retail store handing our cashier an item they've chosen to buy. On that item may be a product number that the cashier could type in. Doing so might add it to the system. Also on that item might be a barcode that they might scan in using some scanning device. If that item isn't marked at all, our cashier might look up the item number for that item. We've now identified three sub-tasks:

• Enter item number
• Scan item number from barcode
• Look up item number

Now, let's pretend this point of sale system will be installed in a gift shop where not all items have barcodes. Scanning might then be a little less necessary than if might be if this was a grocery story. Our cashier could simply enter the item number from a tag on the item. Also, even if the item did have the barcode, he could fall back to just entering the number.

If there was no barcode or item number tag on the item, our cashier would have to look it up. I can imagine there might be a nifty item lookup feature in our software that supports that. I could also imagine our cashier using a less nifty printed product list sitting beside the point of sale device. So, we have an opportunity to turn the "look up item number" task into something that's a manual task not supported by our software. We can make that task even more optional.

Extracting these three tasks from our "add items to point of sale transaction," then ranking the new tasks by necessity might leave us with a span plan that looks like this:

Not how we've annotated the original task card to indicate that we only want to support this task with manual item number entry. Also notice we don't yet have numbers on the two new cards we added. We'll have to do that later as part of documenting this modeling and planning session. We'll likely add new rows into our electronic feature backlog.

Discuss feature ideas and assumptions

It may help estimation for the group to discuss the types of features everyone is envisioning to support your users' tasks. Tasks with high estimates, in particular, may benefit from further discussion. To support this discussion, use a whiteboard or pen and paper to quickly draw low fidelity user interface prototypes.

Record feature ideas and assumptions that estimates are based on directly on the task cards, or on sticky-notes fixed on or nearby the task cards.

We've moved from talking about user tasks to features

Notice how we've had to move from talking strictly about the tasks our users engage in to the software features, or tools they'll need to support those tasks. In the example above we made a tool choice that our cashier could look up an item number using a paper list of item numbers. Our user needed a tool to support that task, but we made a decision that it might not have to initially be a feature in our software.

Estimating and planning requires that we begin to imagine the features we'll need to design and create to support these tasks. Fine tuning the estimates require more thought and at times some preliminary design. Writing user scenarios and creating low fidelity user interface prototypes may expose more opportunities for thinning tasks and ultimately the features that support them.

Close the collaborative session

Before leaving, look over the span plan you created. Fix any loose index cards down to the model using tape. Make any last minute notations.

Someone stand and summarize the model. If you've just constructed the span plan, verbally summarize the progression of activities in the workflow, and the most important tasks within those activities.

If your group has moved on to planning, discuss the releases you've sliced out of your model. Say a bit about the activities and tasks supported in each release. Say a bit about any thinning you needed to do to allow the estimated release date to match up to the ideal release date. Discuss any feature ideas that came up while planning or any assumptions you've made about features.

Record this summarization as a model movie.

Take a model photo.

As a group review parking lots and feed forward bins. Is there any work left to do here or topics to discuss?

The Facilitator indicates who will be responsible for documenting the session. The Documenter lets everyone know where and when they'll see the results of this session posted.

Conclude the session by doing a round of parting takeaways.

Consolidate, Document, and Communicate

Ideally the finished span plan will be posted in a public area visible to the team to serve as an information radiator.

Update your electronic task list

During the creation of the span plan and release planning you'll likely have captured a number of details:

• Changed task names and added additional task
• Feature ideas or assumptions for specific tasks
• Feature development estimates
• Proposed release numbers
• Proposed release dates

Record this information in your electronic task list. You'll likely create additional columns to support this new information. Your electronic task list is beginning to look more like an electronic feature backlog.

Optionally create an electronic version of the span plan

If external communication of this session is necessary, consider creating an electronic version the span plan. This could take hours, so do try to avoid this.

Document important session outcomes

Write up and post notes you've made about the session including the list of collaborators who built the plan, the scope and goal statement, the model photo, model movie, notes or observations made during the session, and the updated electronic task list that came from the session.

If you've estimated feature development times for your tasks, and separated tasks into releases, publish these release dates along with the users tasks supported in each release.

Manage feature design and development from the span plan

Building a span plan will help you understand the activities and tasks that make up a business process, and to plan software releases that best support that business process. But, its job isn't done.

The span plan can continue to serve as an information radiator to help explain the business process to others, and to refresh the memories of those who were there during the model's creation.

The span plan can also function as a starting point for managing decisions to make regarding specific features to design and develop while building the software release.

Add or replace tasks with features you choose to build

The span plan as it's originally created contains the tasks that users of the system need to accomplish within the business process. Throughout the process of designing and building the software your team will make specific choices about the features that best support users in accomplishing these tasks. The span plan can be seen as a design checklist where cards on the plan are tasks that have not yet had specific feature decisions made. As specific feature choices are made, those features can be added to the span plan either in addition to the task cards, or in replacement of the task cards.

The feature card can contain summary information about the feature including a thumbnail sketch of the user interface design or domain model, specific business rules, or specific validation rules. In practice I've attached user interface wireframes into the vertical swim-lane that represents each activity - since activities often share a common user interface.

When feature cards are added into the span plan during design and development, it begins not only to explain the workflow of users using the software but the product feature choices made by the team, and the ongoing progress toward making all the feature choices to support the users of the software.

Mark off functionality as it's built

During the design and construction of the software, I like treating the span plan as a big giant bingo card. For each feature our team implements that supports a particular user task, we mark that task card as complete. Use a felt tip marker to put a big red "x" over the card.

Our development strategy leverages feature thinning guidelines so we attempt to span the full business process with features to support all the necessary tasks as soon as possible. When we've implemented all the features to support those necessary tasks, it's appropriate to shout "bingo!" At that time we've got a functional walking skeleton - enough of the software implemented to demonstrate and validate the entire business process.

Rebuild the span plan

During the design and development of a release, a well used span plan gets marked up with information useful at the time, but not so useful now. Our understanding of the business process matures. We discover new tasks users engage in. We may eliminate some, and decide there are better ways to describe others. Over time you may find this model a little less useful.

To rebuild the model, follow the same general approach you did when initially building it. Print task cards from your electronic feature backlog. However, if you're partway through development, you may want to consider printing feature or story cards to knit into the model showing what functionality you've already designed, or designed and built.

Further reading

Agile Estimating and Planning