trends in agile

CONTENT PROVIDED BY April 2013 | VisualStudioMagazine.com

> Leveling Up Agile Requirements

> The Cost of Stories Page 8

> Unleash the Power of Story Points Page 11

Trends inAGILE

DEVELOPMENT

http://VisualStudioMagazine.com

http://www.kovair.com

mailto:sales%40kovair.com?subject=

Trends in Agile Development

1

Leveling UpAgile Requirements

Mature agile development teams strive to deliver only the smallest amount of functionality and code needed to satisfy a given desirement. They strive for this ideal because even valuable code or capability

added to software has maintenance costs. When code inventory is increased without a corresponding value to the customer, the net value of the software package decreases due to system complexity and the increase of maintenance cost.

Not only does backlog management impact product architecture, but full adoption of experience leveling can also enable faster time-to-production, higher quality and better user experience. BY DAVID STARR

Even valuable code or capability added to software has maintenance costs.

2


Even with a firm understanding of this principle, many teams struggle to implement functionality that is only strictly necessary. Most developers have years of history where software they created goes into the category, “Will be used later.” In some cases, they may have introduced abstractions such as, “Will be needed by Feature X, next sprint.” Yet all too often, Feature X never gets scheduled for implementation.

Experience Leveling is an organizational technique for desirements (or requirements). The technique helps development teams build only what’s necessary, while decreasing time between potential releases.

Let’s define terms. A desirement is a non-compiled request for software to change. Examples include specification documents, Visual Studio Team Foundation Server Work Items, index cards and hope expressed with Microsoft Word.

A requirement, on the other hand, is an automated test proving desired behavior exists in software. Requirements (tests) must pass before software may ship.

Effective use of experience leveling includes not only the code-level approach to software design, but a layered approach to software requirements and the way work is provided to the team. This means those who create and manage requirements are in a powerful position to influence code being created.

Thin SlicesA popular concept to help teams avoid creating unneeded code is thin slicing features. Thin slicing is an evolutionary architecture idea; it proposes implementing only a small bit of functionality, but all the

Experience leveling helps development teams build only what’s necessary, while decreasing time between potential releases.

Figure 1. Thin slicing on a typical layered application architecture.

3


way through the layers of the application. For example, a developer adds only one button to a form, knowing it will eventually need more functionality and controls. Only after making the button work completely, and passing all relevant acceptance criteria, does the developer add the next bit of functionality.

Thin slicing at work on a typical layered application is shown in Figure 1. The development team implements complete end-to-end features or functions in each sprint. While the resulting product increment may not have all functionality customers want and need, every feature present in the software is complete. Each feature is fully functional, tested, validated, usable, and even shippable should the product owner choose to release it.

Successfully transitioning to this way of developing software often takes months. The habits and muscle memory of the development team must change to accommodate this new way of approaching software design. It’s a lot of work, but for teams successfully reaching this state of agility, the dividends are very high. The ability to ship at any time and to only include strictly necessary functionality lies at the very heart of true agility, and increases the value of both the software and the team creating it.

Experience LevelsHow desirements are described, packaged and presented strongly influences product design. Accordingly, it’s reasonable to (at least

The habits and muscle memory of the devel opment team must change to accommodate this new way of approaching software design.

Figure 2. Experience Levels on thin feature slices.

4


minimally) consider software design when creating and ordering the product backlog.

Experience levels provide a container for organizing desirements, which works hand-in-hand with thin slicing. Experience levels progressively reveal functionality as new slices of functionality are added. Consider a typical search engine: Searching the Internet for relevant information is the core experience. The first level of experience might be to search all pages on the Web. The next level of functionality may allow searching only images. The next level of the search experience may allow only searching videos found online. And so on.Experience

levels provide a container for organizing desire ments, which works hand-in-hand with thin slicing.

Figure 3. The Font section on the Home tab in Word Ribbon menu.

Figure 4. A Requirements Map using experience levels.

5

Organizing the product backlog into experience levels is only half the technique. The other half is ensuring the development team actually treats these experience levels as releasable milestones. This might mean reaching zero known defects in the product, exercising the release process in part or in whole, or actually delivering a product increment to customers.

Overlaying experience levels onto the thin feature slices is shown in Figure 2. Each experience level (labeled EL in Figure 2) represents useful functionality and provides value without any other investment.

Experience levels exploit Conway’s Law—”organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”—to influence positive behaviors and outcomes. Teams new to minimalist design and evolutionary architecture can get a jumpstart from using experience levels.

The Word Ribbon Case StudyBecause most of you will be familiar with the Ribbon menu bar in Microsoft Word, it provides a convenient model for demonstrating experience levels. Examples will focus chiefly on the functionality rep-resented by the Font section of the Home tab, shown in Figure 3.

The Home | Font menu experience allows customization of font and typeface within the current document. Organizing this overall experience into logical levels helps the development team focus, while allowing the product owner to ship whenever needed.

The Experience MapOne way of organizing the experience levels for the Font Formatting menu is shown in Figure 4.

The Home Tab consists of several child experiences, one of which is Font Formatting, which itself is organized into EL1-EL5. There’s no upper bound to the potential number of levels for any given EL. Accordingly, ELs may be structured 1-n, in order of decreasing value, increasing complexity or some other criteria.

EL1 is the smallest collection of user stories possible resulting in a usable experience for the customer; it’s the minimum functionality a customer would find valuable. One proposed implementation is shown in Figure 5.

While this functionality may not be enough to delight the customer, or even to ship the product at all, delivering just this much

Experience levels exploit Conway’s Law to influence positive behaviors and outcomes.



6

functionality has several benefits for both the customer and the dev team.

Benefit for Customers Because product owners may deliver the product at the completion of any Experience Level, customers are able to receive more frequent updates to their software. Features are never incomplete or unusable.

Customers may get essential functionality as soon as possible. While customers may hope for (and even deserve) more functionality in future releases, at least some level of experience is available quickly. This provides immediate value without forcing the customer to wait for everything to be delivered at once.

Progressively revealing a feature through experience levels allows work to begin on a feature before fully understanding where the feature may evolve. This concept allows for customer feedback to truly drive the design and implementation of the product, especially when feedback can be gathered after delivering each experience level. This often results in fundamental changes to the ordering of the Product Backlog and the evolution of the product.

Development Team Benefits Experience levels require thinking more deliberately in terms of good UI element segregation. Development teams delivering one experience level at a time get skilled at creating modular and functional UIs.

Ordering work in logical experience groupings also forces the product owner to make deliberate decisions about when to stop adding functionality. This makes it easier to stop investing in a given feature.

Delivering each experience level in sequence naturally limits Work in Progress (WIP). There are many benefits to limiting WIP, the most notable being a significant rise in software quality. Details about limiting WIP is beyond the scope of this article, but delivering experience levels sequentially necessarily forces this practice.

Just like the user stories they contain, the size of each experience level may be estimated by the development team. Experience levels often make good estimation packages because they’re at a level of detail useful for long-term planning.

Because product owners may deliver the product at the completion of any experi ence level, customers are able to receive more frequent updates to their software.

Figure 5. How Experience Level 1 might look in the product.

7


A development team may work on a single experience level for several sprints, while indi-vidual user stories or product backlog items are planned and completed each sprint.

Font Formatting for Levels 2-5As each experience level is delivered, the UI evolves to accommodate and support the new functionality. Figure 6 shows one possible evolution of the UI for the feature.

Better, Faster DevelopmentUsing experience levels effectively yields higher-quality software, faster throughput and clear product management benefits. The renewed focus on UX and evolutionary architecture means faster delivery of fit-for-purpose software.

Getting started is usually quite easy for existing agile teams; consider it a product backlog management technique with beneficial side effects. Customers and development teams alike stand to gain from progressively revealing functionality via experience levels. VSM

David Starr is a senior program manager at Microsoft, where he helps make tools for agile teams using Visual Studio. He has also been chief craftsman for Scrum.org, a five-time Visual Studio ALM MVP, a Pluralsight technical instructor and agile coach.

As each experience level is delivered, the UI evolves to accommodate and support the new functionality.

Figure 6. EL2-EL5 of the Font Formatting Word Ribbon menu.

8


The Cost of Stories

Would you like a cookie? If you ask any child that question, they will likely say “Yes,” even if the cookies are really awful. However, if the child had to choose between a cookie or a piece of candy, they would

have to think about which one they really wanted.I call this “The Cookie Principle.” That is, if you ask a customer if

they’d like to have a feature, they can almost always think of a good reason to have it. However, what you don’t know is the price they would be willing to pay, and every feature comes at the price of another feature.

One of the most important jobs of a product owner is to put price tags on the features. I’ve often seen a product owner and customer go through an intensive stack-ranking exercise, but without the knowledge of cost. The customer typically picks the coolest features and ranks them at the top. I call this “The Window Shopping Principle.”

This is like taking your daughter shopping for a dress, but not going inside the store and only window shopping. Your daughter might pick the prettiest (and possibly the most expensive) dress, but you aren’t done shopping until you know the actual price. That’s when the real trade-offs happen.

One of the most important jobs of a product owner is to put price tags on features.

How can agile teams put price tags on features? Gregg Boer covers two methods that teams can use to estimate costs.BY GREGG BOER

9


A stack-ranking exercise without any kind of cost analysis is like window shopping. Maybe you didn’t know your customer liked feature X, but you aren’t done stack-ranking until the customer knows the price tags for various features, and begins making real trade-offs.

Both The Cookie Principle and The Window Shopping Principle represent the same simple concept: A decision to include a feature should never be made without some cost analysis. Unfortunately, this concept is simple, but often forgotten.

In agile, one of the most common methods for pricing a feature is to use story points. Story points give the customer and the product owner some idea of cost.

Many teams don’t estimate the story until right before they commit to working on it—during the sprint planning meeting. This is like deciding to buy the pretty dress, without knowing the cost until you check out at the register. Some Dads may have the cash to make decisions that way, but most don’t.

An agile team has a limited set of resources that needs to be spent wisely. Simple math tells you that a team of seven people could cost $12,000 to $17,000 a week to run. A three-week sprint can cost close to $50,000. That kind of investment warrants some cost research. Cost is a key piece of information that should be used when spending those resources, and deferring the knowledge of it to the very end isn’t wise.

Story Pointing BlitzTwo simple approaches enable agile teams to do cost research. With the first approach, the team takes a backlog that has been prioritized without cost information. The goal is to quickly discuss each story, and immediately estimate it. If the team is fairly close in agreement on the estimate, someone is designated to pick the estimate to go with, and the team moves on.

A story pointing blitz can be a bit unsettling, however. Engineers love precision, and this isn’t a precise exercise. Everyone on the team should understand the following:

• The goal isn’t to get accurate cost information; it’s to get any cost information. The estimates produced in this meeting are only to put price tags on stories, and to facilitate more productive discussions with the customer.

• This will not be the only time the story will be estimated. It will be estimated again, once the story has been groomed and the team has more information. Knowing this, the team can shorten discussions about whether something is five or eight

In agile, one of the most common methods for pricing a feature is to use story points.

10


story points. The difference of three story points doesn’t mean much in the grand scheme of things.

• The estimates will never be used for commitments. It’s very tempting to take these estimates and begin crunching numbers to determine what features will be done by a certain important release date. The product owner must be very careful with this, because when a feature set is communicated and associated with a specific date, others may turn that information into a commitment, even if that wasn’t the intent.

As fuzzy as these estimates are, it’s amazing how valuable they are when you start trading features against each other. Think of it as scanning Amazon and eBay for prices. It’s not precise cost research, but it’s still useful.

Grooming EstimatesThe second approach is to do the estimates during grooming meetings, before the sprint planning meeting. Estimation almost always comes with emotional and political baggage. Estimating right before a commitment only increases that baggage.

A weekly meeting can be used to groom the stories before they are brought to sprint planning. The product owner presents upcoming stories to the team. The team has time to understand the stories, ask questions, and even push back or offer trade-offs.

It’s a good idea for the team to see the story in one meeting, and estimate it in another meeting. This allows the team to think about it over the week. Amazing ideas can emerge by letting intelligent people ponder something! I’ve seen a team offer amazing solutions that are better and cheaper when they’re given the time to think it over.

After the team believes they understand the story, they estimate it. This estimate is used to make the final prioritization decision: What to bring to the next sprint planning meeting.

If your backlog is like most, it has lots of cookies and pretty dresses. Your job, however, is to give customers the most important features first. VSM

Gregg Boer is a principal program manager at Microsoft with 25 years of experience in software. Over his career, Boer has worked as a project manager, program manager, requirements lead, software engineer, analyst, QA lead and software designer. He joined Microsoft in 2005 because he believed in the vision of Visual Studio Team Foundation Server (TFS). Currently, Boer is working on the team developing a set of world-class agile tools built on top of the TFS platform.

It’s a good idea for the team to see the story in one meeting, and estimate it in another meeting.


11

Story points is a very common practice in agile develop-ment, and even though it’s not mentioned in the scrum guide, many scrum teams consider it a core practice.

Very simply, story points is way to estimate the size of an item on your backlog.

Estimating size is the first step in good estimation. Figure 1 shows how estimation should be done and is detailed here:

• Schedule is a function of the effort (person-hours) required.• Effort is a function of the size of the backlog item. The bigger

the item, the more effort required.• Effort should be calculated using historical data. The past is the

Story points are a crucial aspect of agile development, as they help quantify workload and job estimates. If you’re not using them, you’re missing out. BY GREGG BOER

PHOTOGRAPHY/ILLUSTRATION BY SHUTTERSTOCK/REDMOND STAFF

Unleash the Power of Story Points

Estimating size is the first step in good estimation.

12


best predictor of the future.

Estimating the size of a soft-ware deliverable is not some-thing to which many engineers are accustomed. Teams are often asked: “When will you get Feature X done?” and “How many hours will it take to complete Feature X?” Rarely are they asked: “How big is Feature X?”

Learning to estimate size is the biggest paradigm shift teams need to make to get better at estimation. Estimating the size of software isn’t a new problem: Function points is an example of a sizing metric introduced in 1979, and other sizing methodologies have been tried over the years. The problem isn’t that the other methodologies weren’t successful—it’s that they weren’t accessible, being complicated and difficult to understand.

Understanding story points isn’t hard. Getting started and fully utilizing its power can be.

What Is a Story Point?The hardest part of getting started is defining what “five story points” even means. The team needs to create its own meaning for story points that is unique for them. This may feel daunting, but it doesn’t have to be. To get started quickly, follow these steps:

1. Find a number of representative backlog items the team has already completed.

Figure 2. A team’s past velocity.

Understanding story points isn’t hard. Getting started and fully utilizing its power can be.

Figure 1. Basic principles of estimation.

13


2. Get the team together and have the team decide on what an “average size” backlog item is.

3. Once you’ve picked that item, call it five story points. This is your “golden story.”

4. Celebrate, because you’re done.The golden story is your new reference point for all future

estimations. Now when estimating a backlog item, the question is how it compares to the golden story. Is it a little smaller? Call it three story points. Is it a little bigger? Call it eight story points. Is it quite a bit bigger? Call it 13 or even 20 story points. Is it tiny? Call it one.

The key to success is to not get hung up on the need for precision. Software engineers love precision. That’s a good thing, but you need to let go of that with estimation. Estimation is messy stuff, and invest-ing in more and more precise estimates has a quickly diminishing return. I believe that function points and the other sizing methodolo-gies never hit mainstream because they pursued precision to the point where the methodology became too hard to use or understand.

Figure 3. Estimating a schedule using historical data.

The key to success is to not get hung up on the need for precision.

14


By design, story points are not precise. This is what makes them so approach-able; but they can still be very powerful.

VelocityThe key power in assigning story points to items up front is to collect historical data, also known as velocity. Velocity is the number of story points the team completes in a given time period, typically a sprint. Figure 2 shows a team that’s completed four sprints. The numbers represent the total story points completed in each sprint.

Velocity goes up and down with sprints, with an average of 20. This same team has about 20 items on its backlog that are story pointed. The total story points for the remaining 20 items is 120 story points, as shown in Figure 3. It’s fairly simple math to see that it will take your team about six more sprints to complete the 20 stories.

Figure 4 shows the application of the simple estimation formula: You’re using size (story points) to calculate effort (the entire team working for a sprint), based on historical data (your velocity) to calculate schedule.

This is powerful because maybe for the first time, you have actual data backing an estimate. Assume an executive says, “We need to get those 20 items done in three sprints, or we might as

By design, story points are not pre cise. This is what makes them so approachable; but they can still be very powerful.

Figure 4. Applying the basic principles of estimation.

Figure 5. A team estimating bugs with story points.

15


well all pack up our desks and go home.” (Yes, I have actually had executives say that to me … a couple of times.) Without historical data, it’s difficult to push back. But even with a few sprints of data, you can confidently say three sprints isn’t possible, and you’ll more likely need six sprints.

Are these estimates precise? Not really. You don’t know that it will take precisely six sprints. It may take only five sprints, it might even take seven. That’s expected variability in any estimate. Most important, you have high confidence that it won’t get done in three sprints. And you’re able to keep your team from a death march toward an impossible goal.

Which Items to Story PointA question that always comes up: Which backlog items should be story pointed, and which ones shouldn’t? For example, should the team story point bugs? Should it story point spikes? What about improvement items?

The answer’s simple: Story point only the types of items on your product backlog. Assume the team in the example decided to story point the bugs it fixed in a sprint. Figure 5 shows an example of what that might look like.

On average, each sprint has five story points of work on bugs. This means your average velocity on new features is actually 15. Most backlogs don’t have backlog items representing the bugs expected to be fixed in the future. If the product backlog in Figure 3 represents new features, then using 20 as velocity won’t give a

Story point only the types of items on your product backlog.

Figure 6. A team estimating spikes and bugs with story points.

16


good estimate—instead, the team should be using 15. If the velocity’s off by that much, it could result in the team convincing the executive it needs six sprints, when it will actually take eight.

Suppose the same team worked on a few spikes in those sprints, and they were story pointed as well. Figure 6 shows how this might look.

The team’s velocity on features is actually 13, which compared to the 20 items on the backlog means it would need more than nine sprints to complete them.

Process improvement items may or may not be on your backlog. If they are, they should be included in the story points counted toward velocity. If not, the team should leave them out.

To accurately use historical data to estimate the future, what the team counts toward their velocity must match what it’s estimating in its backlog.

Teams that know how to use story points have an extremely powerful tool. Often, the question, “When can we get this done?” comes with so much emotional baggage attached to it, that teams are forced into an impossible deadline. Armed with data, the team can bring logic back into those discussions; this is a very good thing, indeed. VSM

Gregg Boer is a principal program manager at Microsoft with 25 years of experience in software. Over his career, Boer has worked as a project manager, program manager, requirements lead, software engineer, analyst, QA lead and software designer. He joined Microsoft in 2005 because he believed in the vision of Visual Studio Team Foundation Server (TFS). Currently, Boer is working on the team developing a set of world-class agile tools built on top of the TFS platform.

Teams that know how to use story points have an extremely powerful tool.

trends in agile

Documents