how you slice it


1 Manage People & Projects It’sAllin HowYou Slice Slice Design your project in to avoid working layers half-baked incremental SUPPOSE FOR A MOMENT YOU’RE IN CHARGE OF releases. BY JEFF PATTON development at BigNewIdea Software. You’ve adopted an Agile development approach that suggests releasing your software in smaller incremental releases is a good idea. BigNewIdea’s marketing folks and business managers exclaim excitedly, “If we build the highest- value features first, the users will love our first release!” You develop for a few months, always shifting the highest-value features to the top of the stack. You eventually release a well-built, rela- tively bug-free release. First responses from people using the software seem positive. “This looks really good!” they say. “It’s got all these features we’ve wanted for a long time!” But strangely, sales seem to be slower than expected. Salespeople find that many customers who have pur- chased the software aren’t actually using it. “What’s wrong?” marketing asks through question- naires and expensive focus groups. The reply: “What you have is fine, but there’s not enough here TOM SCHIERLITZ/GETTY IMAGES 16 BETTER SOFTWARE JANUARY 2005

2 It It FPO

3 Manage People & Projects around in your model. I’ve found it’s easy as domain experts, testers, and user inter- for me to get my job done. I still have to to merge features originating in a spread- face designers. Choose people who have do much of my work manually. I have to sheet with a word processor document some ideas on how the software will earn transfer information from my paperwork 5 cards that will print them on precut 3 × your company money—your stakehold- to the software and back again. Some- or business cards. This way, the cards are ers. Choose people who know something times I can’t even figure out a paper easy to read and work well within a card- about how long this work will take to workaround. I’ll wait for the next release modeling exercise. Leave room under the build—a developer or two. Four to eight to see if you get farther along.” feature statement for the details we’ll add in Steps 2 and 3. [When releasing] software incrementally, Suppose I’m building some software for small retailers. I know that their busi- a first how do you choose ness processes go a bit like this (notice that each one starts with an action verb): bundle of features that is both high value and immediately useful?  Create purchase order for vendor  people total is a good number. Use the You expected that all those high-value Receive shipment from vendor creation of the model as an opportunity features would make a great product, but  to elicit discussion about the features be- it turned out you needed some of those Create tags for received items ing built. low-value features to hold everything to-  gether—to make the product useful to Sell items those trying to accomplish work with the STEP 1: COLLECT FEATURES  software. If you still want to release the With the prep work done, it’s time to Return and refund items software incrementally, how do you start assembling the model. The first step  choose a first bundle of features that is is to answer the question “What does our Analyze sales both high value and immediately useful? software do?” You should start with a user-centric list of features. De- STEP 2: ADD DETAILS pending on your situation, this To help you model these features, let’s might be trickier than it sounds. note three important details on the My definition of a good feature cards: who uses the feature, how often Key is one that is expressed from a the feature is used, and how valuable the user’s perspective. For example, if I feature is. Ingredients were building new software for a First, for each feature, detail the kind retail store, a feature might be “sell of user who uses it. When describing this 2–3 large sheets poster paper items at point of sale” as opposed feature, you likely envisioned someone 3–4 packs markers to “the system supports EAN-13 using it—who was he? You can identify 1 roll tape barcodes.” There’s a difference him with a job title, a role name, a per- 1–2 packs 3 × 5 index cards there that I hope is not so subtle. sona, or in any other way most appropri- Plus, the fundamental element of all good The first feature describes an activ- ate for your system. (See this issue’s meetings: food. ity done by a person; the second StickyNotes for more on roles.) describes an attribute of an object. Looking back at my set of retail store Look for features that start with or features, I know that the same person include some action verb; that’s a usually doesn’t do all this stuff. I know good sign. When describing your soft- In this article, we’ll walk through a sim- that the work is divided between mer- ware, it helps to indicate how it will be ple, collaborative, card-based planning chandise buyers, stock receivers, cus- used rather than how it might look or the model that does just that. tomer consultants, and sales analysts. I details of its implementation. Keeping note each user under the feature state- your focus on the usefulness of the soft- PREP WORK ware at this stage helps to ensure that the Before you begin, you need to choose a create po bits of software released incrementally good cross section of folks to participate will be useful. in creating the model. While the model for vendor If you’re not already describing fea- could be prepared by one person, I (merchandise buyer) tures for your software in a user-centric wouldn’t recommend it. Having a mix of frequency: weekly way, you may need to spend a little time people will help increase understanding reframing your features. of the software throughout the team. value: medium 5 cards or on × Write the features on 3 Choose people familiar with the users something else that you can easily move and functionality of your software, such A completed feature card. Figure 1: BETTER SOFTWARE JANUARY 2005 18

4 Manage People & Projects Tips for Success release or a prior one. I’ve found that if I slice releases horizontal- When assembling the batch of features for your project, pay at- ly starting from the top of the model down, I rarely run into de- tention to the following details to help ensure success. pendencies I haven’t already resolved in a previous release. When using use cases, focus first on those where the actors Sometimes folks suggest features that aren’t really about users are a single user and the system. Avoid planning with use cases and the functionality they need. Features like “migrate to an Oracle that describe the internal workings of the system. Avoid use cas- database” or “change the look and feel to match our new brand- es that describe business processes at a very high level; make ing.” These sorts of features don’t work well in this type of model. them what author Alistair Cockburn calls “sea level system scope When talking about certain features, you might find it’s tough use cases.” to defer some of them completely. When slicing off a set of fea- If you’re using user stories, include a user of the feature in a tures to release, discuss how usable that release will be. For each concise story statement, such as the one author Mike Cohn cred- user of the system ask if she will be able to do her work with this its practitioner Rachel Davies with inventing: As a [type of user] I subset of features. For each important feature left out, is there a want [some particular feature] so that [some benefit is received]. paper process or software workaround that allows her to live For example: “As a bank customer I want to view my current ac- without the feature—no matter how annoying that might be? count balance so that I know my recent deposit went through.” Could the feature be split into a crude minimal version for earlier The completed model shows us features arranged in the order release and a more elaborate version for later release? they’re needed by people and business processes, but this really See this issue’s StickyNotes for some reading that will help only gives us an indication of dependence. As you slice off releas- ensure a good outcome. es, scan each feature for dependencies that might not be in this but nothing about value. You’ll find with sheets and tape them together to form a ment he is involved with. a good mixed collaborative group, you’ll broad poster. Next, note how frequently you be- be able to quickly fill in all these details. Draw a horizontal line across the top lieve each feature will be used. You can You’ll notice lots of good discussion of the page and label it use simple notation like high, medium, or usage sequence. while doing it. low. I use a little more precise continu- Draw a line on the left side of the When writing your features on cards, um, writing under the user on the feature page from top to bottom and label it crit- the same information should appear in card either hourly, daily, weekly, month- Label the top endpoint of this line icality. the same place all the time. This makes ly, or quarterly. always used, the bottom endpoint sel- the cards easy to read when placed in the Finally, for each feature, note its value The resulting diagram should dom used. model. They might start to look like to the purchasers of this system. If your look like the one in Figure 2. playing cards in a game. That’s good. company has a good understanding of You now need to place features in the Building the model should feel a bit like where ROI comes from on this system, model according to usage sequence and you’re playing a game. this may not be too hard—but for the rest criticality. By using the features we wrote of us, this is usually a subjective judg- out for our retail software earlier, we’ve ment. Using high, medium, and low will already listed them in the order the fea- STEP 3: PLACE CARDS IN work fine for our use today. I’ll write the tures will be used. PO creation happens SEQUENTIAL ORDER value under the frequency on each card. before shipments are received from the To build this model, lay a few sheets of When all of these details have been vendor. Tags are created before the items poster paper on a large worktable. This added, one of the feature cards might are put on the shelf and sold. Sales are model is generally wide, so arrange look like the one in Figure 1. Usage Sequence When trying this at home, make adding these details a collaborative activ- always used ity. Assuming you’ve got your features written or otherwise printed on cards, spread those cards out on the table. Take turns picking up cards and adding user, frequency, and value. If you’ve got a Criticality good mixed group, you’ll notice that some folks have strong opinions about seldom used some of these details. Some folks may know a bit about the user and frequency, Figure 2: The model starts with an x and a y axis. JANUARY 2005 BETTER SOFTWARE 19

5 Manage People & Projects a manner as possible, place the cards in placed with vendors informally over the analyzed after some items are sold. your model by usage sequence, with fea- phone without a purchase order being That’s what I mean by usage sequence. tures used early on the left and later on created in the system. So in those cases, In reality, it may not seem so cut and the right. Have them overlap features we’ll receive the items into inventory dried. If we really look at a retail store, that might happen at about the same without a PO. This is generally the ex- we might find buyers on the phone plac- point in time. If someone gets confused ception, but it happens and should be ing orders at the same time receiving about the position of a feature, suggest supported. So our feature “create PO for clerks are in the back room receiving and vendor” is important to our system and always. is used frequently, but not In reality, it may not seem so cut and As a group, adjust vertical positioning of your cards based on how critical they dried. . . . It looks like all these features are to the business process. If the feature is always done, place it on the top. If the are being used simultane- feature is often —but not always—done, and indeed they are. ously place it a bit below the top line. If it’s sel- dom done, place it toward the bottom. If that he look at the feature and its imme- you’ve got enough people working on tagging. If the store’s open, we hope cus- diate neighbors. It’s sometimes easier to the model simultaneously, this may start tomers will be on the retail floor happily answer the question “does this happen to look like a game of Twister. You’ll ob- buying our products and customer con- before that” than to try to take every- serve people moving cards down only to sultants will be ringing them up. It looks thing into account at once. see them adjusted back up by someone like all these features are being used si- If we arranged our feature cards in se- else. Use these conflicting card move- multaneously and indeed they are. So quence, it might look a bit like the dia- ments to elicit discussions on why some- when sequencing them in your model, gram in Figure 3. one might believe a particular feature is arrange them in the order that seems log- more critical than another feature. ical when explaining to others the busi- If we adjust our features for criticality, ness process. If you explain the business STEP 4: GROUP BY our model might look a bit like the one process starting with the selling part, FREQUENCY in Figure 4. that’s OK, put that feature first. We want For each of these features, how critical to this model to help us tell stories about our business is it that someone actually our software, so arrange them in an or- uses it? Let’s look at our retail features: STEP 5: NOTE LOGICAL der that makes it easy to tell stories. When working with the business people BREAKS IN WORKFLOW Distribute the cards among partici- who know how their business is run, If your system is anything like those I’ve pants. Then have everyone, in as orderly they inform us that orders often are worked on, you’ll have knitted together a few distinct processes done by different people at different times. When you look Usage Sequence across your model from left to right, you always used might start to see logical breaks in the create tags for sell items analyze sales receive shipment create po received items for vendor from vendor (customer consultant) (sales analyst) workflow. Remember how for each fea- frequency: hourly frequency: monthly (stock receiver) (stock receiver) (merchandise buyer) value: high value: high frequency: weekly frequency: daily frequency: daily return and ture you noted a type of user or role that value: medium value: medium value: high refund items (customer consultant) primarily used the feature? You’ll find frequency: daily value: medium that these breaks often occur when there’s Criticality a role change. Reading left to right you’ll see some features are used by one role, seldom then you’ll see a change to another role used with some features used by this next role. The features cards are first arranged by sequence. Figure 3: As a group, discuss where you see Usage Sequence breaks or pauses in the business process. Then, at each break draw a vertical line, always used receive shipment sell items dividing the model into something that from vendor (customer consultant) frequency: hourly (stock receiver) looks a bit like swim lanes. Label the re- value: high frequency: daily value: high sulting columns for each process as shown in Figure 5. If you’re finding it return and create tags for analyze sales create po hard to divide the model in this way, dis- received items for vendor refund items Criticality (sales analyst) frequency: monthly (stock receiver) (merchandise buyer) (customer consultant) cuss why. Is there really only one type of value: high frequency: weekly frequency: daily frequency: daily value: medium value: medium value: medium user doing one process? Or, do we have seldom used different user’s features mixed up in the same timeline? The sequential feature cards are then staggered according to criticality. Figure 4: 20 BETTER SOFTWARE JANUARY 2005

6 page 21 full-page ad SQE

7 Manage People & Projects This is all quite interesting so far, but Usage Sequence what are you learning about how to always SELLING ANALYZING RECEIVING BUYING used build releases for your software? Let’s sell items receive shipment take a closer look. from vendor (customer consultant) frequency: hourly (stock receiver) value: high frequency: daily value: high STEP 6: MARK THE FIRST SYSTEM SPAN analyze sales create po create tags for return and Criticality refund items for vendor received items Now we’re going to divide the model (sales analyst) frequency: monthly (customer consultant) (stock receiver) (merchandise buyer) value: high frequency: weekly frequency: daily frequency: daily into what I call system spans. (The Pop- value: medium value: medium value: medium seldom pendiecks introduced me to the term used “span” in their book Lean Software De- Figure 5: The model is vertically divided into business processes. velopment. ) A system span is a set of fea- Usage Sequence tures that group together logically and that cut through the business processes always RECEIVING BUYING SELLING ANALYZING used horizontally from start to finish. receive shipment sell items from vendor The first span should be the smallest (customer consultant) (stock receiver) frequency: hourly frequency: daily value: high set of features necessary to be minimally value: high useful in a business context. In our mod- System Span el, it turns out that the very top row (re- return and analyze sales create tags for create po Criticality refund items for vendor received items (sales analyst) ceiving and selling items) is the first, most frequency: monthly (merchandise buyer) (customer consultant) (stock receiver) value: high frequency: daily frequency: weekly frequency: daily minimal system span. This will be true of seldom value: medium value: medium value: medium used your model, too. Draw a line under the top row of your model to indicate the The first system span represents the smallest set of features necessary to Figure 6: features that make up this first system be minimally useful in a business context. span, as shown in Figure 6. built any functionality to support the The first span represents the most the “big picture” helps them estimate a merchandise buyer or the sales analyst. concise set of features that tunnel little better. (See this issue’s StickyNotes Ultimately, we know that supporting through the system’s functionality from for more guidance on quick estimation those folks with some functionality is im- end to end—the bare bones minimum techniques.) portant. But, because the work they’re anyone could legitimately do and still Once you have rough estimates, add doing doesn’t always happen, we can de- use the system. This small span should up the estimates for the features above fer it at least for a little while. always be your first release, but it need the line marking the first span. This is After drawing the line in your model not be the first public release of your how long it should take to build. are there roles and business processes software. Getting this part completed that are omitted? Talk about them as a and released, even if only to internal test STEP 8: SLICE AND SERVE group. environments, forces resolution of both The plan may now be “sliced” horizon- the functional and technical framework tally into subsequent system spans, or of your application. Your testers will be spanning releases. Well, sort of horizon- STEP 7: FILL IN BUILD able to see if the application hangs to- tally. Choose features below the marked ESTIMATES gether coherently. Your architects will first span that group together logically. OK, so building a first span is a good be able to validate the tech-stack func- Choose enough features such that the idea, but how long will it take? If you’ve estimated elapsed development days fit within an appropriate release date. This A system span is a set of features that may cause you to draw lines that wan- der up and down to catch and miss fea- group together logically tures while traversing the model from left to right. Lines drawn through the and that cut through the business plan make it start to look like a haphaz- processes horizontally from start to finish. ard layer cake. At this point in the collaborative ac- tions as expected and may begin work- tivity, the business people responsible got developers participating in this exer- ing on load tests to validate scalability. for the release should step forward. Let cise, and you should, this is a good time The team can begin to relax knowing them use their best judgment to decide for them to start giving development es- that from here on in they’re adding what features best make up a release. If timates for each feature. Write the time more features to a system that can be re- you’re an observer, ask questions so you estimates in days or weeks directly on leased and likely used. understand why one feature rather than the cards. Very rough estimates will do Notice how in the example we’ve not fine. Developers may find that seeing (Continued on page 40) BETTER SOFTWARE JANUARY 2005 22

8 page 23 full-page ad SPI Dynamics

9 Manage People & Projects (Continued from page 22) another finds its way into an earlier re- lease. Responsible business people continue to slice your “cake” into appropriate re- leases. When choosing features to fill a release, you may want to consider the features with the highest value first. You hi-res may also want to consider building up TK support for a particular type of user or business process. In a release, you might try completing all the valuable features in one of your business process columns. This will result in some funny-shaped lines stretching from left to right. After slicing the model into releases, you should be able to see how many re- Figure 7: A real-life model is much more complex and spans several business leases it will take to build this software processes. and what might be contained in each release. shown in Figure 7. Notice in this model Now, let’s get real. Most software THE RESULTS that software spans several business worth writing has more than six features. Because you’ve arranged features in se- processes. Notice how the releases cut Depending on the granularity of your quential order, you now understand what from left to right in some funny jagged features, you’ll likely have dozens. With features depend on one another. Because lines that catch the features the planner a reasonable number of features your you’ve arranged them by criticality, the intended for each release. plan will likely look like the photo important features are now emphasized at the top of the plan. Because you’ve di- vided the features into business process- es, you have a better idea of the function- ality that supports each major business process in your software. You have deter- mined the minimal feature span that lets you get your system up and running, end to end, as soon as possible. All this infor- mation is provided in one convenient pic- ture. By employing a little common sense, we should be able to carve off the smallest possible releases that will still be useful to the people who ultimately re- 1/3 ceive those releases. Incremental release may be one of the square more valuable aspects of the various Ag- ile development methodologies. An early left release can help capture market share, generate early return on investment, and reduce money risked on software devel- Rally opment. A strong early release can in- crease those benefits immensely. The model we’ve built can give you a better picture of your software’s features and help your organization construct the most useful and coherent early release possible. {end} Jeff Patton leads teams of Agile develop- ers to build the best software possible. He proudly works at ThoughtWorks. BETTER SOFTWARE JANUARY 2005 40

Related documents