Authoring Requirements in an Agile World 05162009-313E

8/8/2019 Authoring Requirements in an Agile World 05162009-313E

1/13

Authoring Requirementsin an Agile World

Equipping & Empowering the Modern BA

By Tony Higgins, VP Product Marketing

www.blueprintsys.com

[email protected]


2/13

Authoring Requirements in an Agile World | Blueprint Whitepaper

OVERVIEW

The principles o agile development were proven beore agile as a dened approach became vogue. Agileprinciples were being practiced to varying degrees in most organizations as a natural reaction to the issuessurrounding a rigid waterall approach.

Every individual task on a sotware project carries some degree o risk. Whether the task is planning therollout, perorming a test set, designing a certain component, or holding a requirements review there isa risk that the task may not turn out as planned. There are many sources o these risks some 3rd partycomponent may not unction as advertised, some module your work is dependent on may not be availableon time, inputs to the task were ambiguous and you made an incorrect assumption when lling in the

blanks, the list is endless. All these risks or the individual tasks contribute to the overall project risk and,quite simply, risk isnt retired until the task is done. Putting it another way, the risk associated with building

something is really only retired when the thing is built. Thats the principle behind iterative & incrementaldevelopment.

So instead o leaving the rst unveiling o a new or enhanced application until toward the end o the project,

break it down so that pieces (unctional pieces) that can be built incrementally. While this doesnt alwaysmean the portions are complete and shippable stakeholders can see them working and try them out. Thisoers several advantages rst it retires risk as mentioned beore. It oten also exposes other hidden risks.These risks will surace at some point, and the earlier the better. Exposing hidden risk and retiring risk earlymakes the estimating process more accurate and increases the probability o delivering applications o valuethat address the business needs in terms o capability as well as budget and schedule needs.

While agile is becoming mainstream on small & mid-sized projects, challenges do exist elsewhere such ashow to manage such an approach on larger projects and in distributed development. Another challenge ormany is how to apply a requirements liecycle to agile projects. Many agile principles such as just enoughand no more, to begin development beore all requirements are complete, to test rst, can be counter-intuitive. Also, what about non-unctional requirements? What about testing independence? How can we

cost something i we dont know what the requirements are?

This paper attempts to describe some ways to handle these challenges. It is based on an example o real,ongoing, and very successul product development that uses agile with a globally distributed team. Itdescribes one set o techniques that is known to work.


3/13


PROCESS OVERVIEW

There are many favors o agile, but at a high level they all essentially adhere to the ollowing basicprinciples:

Requirements details as well as macro level scope are expected to change as we progress through ourrelease.

For the purposes o this paper, our example uses a Scrum-based Agile process. In this approach theiterations (sprints) are two weeks in duration. A sprint is a complete development cycle where the goal is to

have built some demonstrable portion o the end application. It should be noted that while the initial sprintsdo involve building a portion o the application, oten times this is inrastructure-level sotware thats neededto support eatures to be developed in later sprints meaning there may not be much or stakeholders tosee.

Each organization needs to determine the sprint duration thats optimal or them. It needs to be long

enough to actually build something, but not long enough or people to become deocused and go o track(thereby wasting time & eort). We ound two weeks to be optimal or our environment.

Key during the rst part o the process is to determine and agree on project scope, also known as therelease backlog. Determining the release backlog itsel could be a series o sprints where the productowner and other stakeholders iterate through determining relative priority or value o eatures along with

high level costing o these eatures to arrive at a release backlog.


4/13


At the other end o the project, development o new code doesnt extend to the last day o the last sprint.We typically reserve the last ew sprints, depending on the magnitude o the release, or stabilization. Inother words, in the last ew sprints only bug xing is done, and no net new eatures are developed. Thistends to go against the Agile purists approach to sotware development as each sprint should in theorydevelop production ready code. However to truly achieve that, requires signicant testing and buildautomation that most organizations dont have in place. This is always a good goal to strive towards, but

dont expect to achieve this right away.

REQUIREMENTS DEFINITION IN THIS PROCESS

There are several ways you could perorm requirements denition in an agile process, but again our goal is tointroduce an example thats been tried and is known to work. This example begins with the assumption that

you already have a good sense o the business need, either inherently in the case o a small and cohesivegroup, or by having modeled the business processes and communicating in a way that all understand. So webegin at the level o dening requirements or the application.


5/13


REQUIREMENTS AT THE BEGINNING

Begin with a high-level list o eatures. Each eature is prioritized by Product Management or BusinessAnalysts (depending on your organization). These eatures are typically then decomposed to urtherelaborate and provide detail and are organized by older groupings and by type. The ollowing image showsan example:

Figure 1 Example High-Level Feature List

I needed to better communicate you should create low-delity mockups or sketches o user interaces (orportions) and even high-level Use Cases or abstract scenarios to express user goals. We sometimes do these

and sometimes not, depending on the nature o whats being expressed plus considering the audience werecommunicating with. For example, i were communicating a airly simple concept (how to select a fight)and our audience is amiliar with the problem space (theyve built fight reservation applications beore) thenclear textual statements may be just enough to meet our goals at this stage. These goals are to establishrough estimates (variance o 50-100%) and based on these and the priorities, to agree on the initial scope othe release (what eatures are in and which are out).

Once reviewed, this list o eatures becomes the release backlog. The eatures are then assigned to the rstseveral sprints based on priority and development considerations.


6/13


Figure 2 Example High Level Features with Properties

REQUIREMENTS DURING THE SPRINT

With respect to the requirements, the principle o just enough is paramount. I the need has beenexpressed to a degree adequate enough to communicate and have it built as intended, then youredone. Going urther provides no additional value. This means youll have a varying level o detail or therequirements across the breadth o the product. For some parts o the product a high-medium level o detai

may be just enough, while or other more complex areas a very ne level o detail may be needed.

In each sprint there are tasks o every discipline taking place. Requirements, design, coding, integration,and testing tasks are all being perormed concurrently or dierent aspects o the system. The requirementsbeing dened in one sprint will drive design and coding in a subsequent sprint. The net eect is that all thesdisciplines are active in every sprint o the liecycle, but the relative emphasis changes depending on what

stage youre at in the project. For example, Requirements tasks are being perormed in all sprints, but theyare emphasized more in the earlier sprints.


7/13


Figure 3 Disciplines by Sprint throughout the project

In each sprint the high level eatures are elaborated into greater levels o detail. This more detailedexpression o the requirements usually begins with usage scenarios/stories and/or visuals and its expressedin the orm o a model. The models can emphasize user interace, use cases, scenarios, business rules, andcombinations o these depending the nature o what is being expressed. Sometimes these are created

collaboratively but more oten in our experience one person creates an initial version and then holds a reviewwith others or eedback. In our case it is typically the Product Managers and/or Business Analysts whocreate these models and usually between one to three reviews are held with the developers, testers andother stake holders. The review serves multiple purposes including

Tofacilitateknowledgetransfertoallstakeholdersincludingarchitects,UEdesigners,developers,testers,and executivesponsorsonwhatisneeded Toallowthearchitects,UEDesignersanddeveloperstoassessfeasibility

Todetermineifthereissufcientdetailintherequirementstoallowdevelopmenttoproceed

With appropriate technology tests are automatically generated rom the requirements producing tests that

are 100% consistent with the requirements and enabling the immediate testing o code developed duringsprints.

CONTINUOUS AND ADAPTIVE PLANNING

With this approach planning is continuous and adaptive throughout the liecycle allowing resources to beredirected depending on new discoveries that come to light during each sprint. This ability to course correctin mid-fight is what gives projects their agility. At the end o each sprint we take stock o what wasachieved during the sprint and record progress actuals. The work o the next sprint is adjusted as necessary

based on this but also based on testing results, eedback rom reviews o that sprints build, any new risks


8/13


or issues that suraced or others that were retired, and also any external changes in business conditions.

Estimates and priorities are adjusted accordingly and any changes to release scope and sprint plans aremade. In general we try not to make major mid-fight corrections during a sprint, which is one o the reasonswhy we like 2 week sprints. I sprints were say 4 weeks then we would lose agility. Also a 2 week sprint is

easier and more accurate to estimate than a 4 week sprint.

With respect to the requirements, or those eatures assigned to the sprint along with any high-levelrequirements models, development creates high-level goals or the particular eature and estimates them.The goals express what aspects o the eature they will attempt to build during that sprint, recognizing thatone sprint is oten not enough time to implement an entire eature. The eature and its high-level goals

become the content o the Story. Once the story is dened the developer then details and estimates thetasks to be done or that story over the next two weeks (sprint) and proceeds with development, tracking

daily progress against these tasks in an agile project management tool and covering issues in the daily scrum.

Figure 4 Example Story with Tasks, and estimates


9/13


WHAT ABOUT THE NON-FUNCTIONAL REQUIREMENTS?

The various agile approaches have evolved several techniques to express system unctionality. These arethings like user stories, use cases, or usage scenarios, that represent observable system behaviors andartiacts that deliver value to users like screens, reports, rules, etc. These unctional requirements expresswhat the system is to do. Examples o this could be things like Generate a stock-level report, Make acar reservation, Register or a webinar, or Withdraw cash.

Associated with the unctionality o a system are its qualities. These express how well the systemis supposed to do what it does how ast, how reliably, how usable, and so on. Sometimes these non-unctional requirements are associated with certain unctional requirements and other times they applyto whole portions o the system or the entire system. So how do these very important requirements getaccounted or in our agile process?

First they are expressed at the high-level in the orm o textual statements. For example: Any bookingtransaction shall be able to be completed by a user (as dened in section a) in less than three minutes, 95%o the time.As unctional requirements are decomposed and derived any associated non-unctional requirements shouldsimilarly be decomposed, derived, and associated to lower levels. For example the above perormancerequirement is associated with all the booking transaction unctional requirements (book a car, booka fight, book a hotel). I the unctional requirements are decomposed into the lower level requirementsselect a car, choose rental options, and check-out, then the non-unctional requirement may similarlybe decomposed into requirements or selecting a car in less than 30 seconds, choosing options in less than 1

minute, and checking out in less than 1.5 minutes.

During review sessions the unctional requirements take center stage. However, during these reviews anynon-unctional requirements that are relevant need to be presented and reviewed as well. Traceability isusually relied on to identiy them.

Any non-unctional requirements relevant to the unctional requirements o the story need to be expressedas part o the story so the developer can take these into account during development.

QA needs to create tests to validate all requirements, including the non-unctional requirements. Sometimesbeore a eature has been completely implemented non-unctional requirements can be partially tested ortested or trending, but usually cannot be completely tested until the eature is completely implemented

(which can take several sprints).

WHAT ABOUT TESTING?

The high degree o concurrency in Agile processes means that testing is perormed in every sprint o the

liecycle. This can be a considerable change rom traditional approaches and oers several benets. First,it tends to oster a much more collaborative environment as the testers are involved early. It also o coursemeans that items which wouldnt have been caught until later in the liecycle are caught early when they canbe xed much more cheaply.


10/13


In agile, Product Owners play a very big role in the testing process and they do so throughout the

development liecycle. Whereas many traditional approaches oten rely on requirements specications asproxies o the Product Owners, agile places much more reliance directly on the Product Owner eectivelybypassing many issues that can arise rom imperect specications. In addition to the Product Owners,

Developers test as well. Test-driven development is a prominent technique used by developers in agileapproaches where tests are written up-ront and serve to guide the application coding as well as perormautomated testing which helps with code stability. To augment test driven development, which is primarilyocused at the code level testing done by developers, new technologies that can auto-generate unctionaltests rom unctional requirements enable a QA team to conduct unctional testing based on test cases thatare not out o sync with the requirements specication. This enables the QA team to conduct testing on a

continuous basis since executable code and test cases are available throughout the liecycle. In our exampleall three are employed - Product Owner, development sta, and independent QA on a continuous basis.

The requirements that we develop in our example are a decomposition o high-level text statementsaugmented by more detailed requirements models that give a rich expression o what is to be built.Requirements reviews are based on simulations o these models and they are incredibly valuable or a

number o reasons. First, just as agile provides huge benet by producing working sotware each sprint thatstakeholders can see and interact with, simulation lets stakeholders see and interact with virtual workingsotware even more requently. Second, people oten create prototypes today trying to do much the samething. The dierence with prototypes however is that simulation engines built or requirements denition arebased on Use Cases or scenarios and thereore guide the stakeholders in how one will actually use the utureapplication, providing structure and purpose to the requirements review sessions. Prototypes, including

simple interactive user interace mock-ups, on the other hand are simply partial systems that exist and

provide no guidance as to how they are intended to be used. Stakeholders have to try to discover this ontheir own and never know i theyre correct or i something has been missed. It is important to note that theprinciple o just enough still applies when producing these models we rely on the requirements reviewsessions held with designers/developers to determine when it is enough. This approach produces veryhigh quality requirements and it is rom these requirements that the tests are automatically generated. In

act, such thorough testing at such a rapid pace without automatic test generation is likely not possible.

Although we strive to have shippable code at the end o each sprint, this goal is not always achieved, andwe may need to use the last sprint or two to stabilize the code. Since testing has already been taking placecontinuously beore these nal sprints, the application is already o considerably high quality when entering

the stabilization phase, meaning risk is manageable and rarely is ship date missed.

WHAT ABOUT ESTIMATING?

Remember in agile it is typically time that is xed in the triad o time, eatures, and quality. In our approach

also remember that with continuous testing and the reserving o the nal sprints or stabilization, qualitytends to be airly well known as well. This leaves the eatures as variable so what were actually estimating isthe eature set that will be shipped.


11/13


As always, the accuracy o estimates are a unction o several actors but Im going to ocus on three

thequalityoftheinformationyouhavetobaseestimateson, theinherentriskinwhatyoureestimating,and

theavailabilityofrepresentativehistoricalexamplesthatyoucandrawfrom.

Estimates are made throughout the development cycle in our approach beginning in the initial scoping

sprints. As mentioned earlier once the list o candidate eatures is known and expressed at a high (scoping)level, they are estimated. Naturally at this point the estimates are going to be at their most inaccurateor the project liecycle since the requirements have not been decomposed to a detailed level (quality oinormation), meaning there is signicant risk remaining in the work to be done. Similar projects done in thepast may help mitigate some o this risk and help increase the accuracy o the estimates (e.g. weve done ten

projects just like this and they were airly consistent in their results).

The initial estimates are key inputs to the scoping and sprint-planning processes. As the project proceedswith each sprint risks are exposed and dealt with, requirements are decomposed to ner levels o detail, andestimates naturally become more accurate. As you might guess, estimation is done toward the end o eachsprint and is used in the planning o uture sprints.

WHAT ABOUT DISTRIBUTED TEAMS?

Today distributed development is the norm. For reasons o eciency, cost reduction, skills augmentation,or capacity relie, distributed development and outsourcing is a act o lie. Theres no ree lunch however

there are costs associated with this approach, and much o these costs are borne in the requirementsliecycle. Chie among these is communication. There are practices and technologies that can mitigatethis issue, so that the promised benets o distributed development can be realized. The approach in thispaper or example uses the ollowing and has been very successul:

concertedeffortformorefrequentcommunication(dailyscrums,andotherscheduleddailycalls) liberaluseofrequirementssimulationviaweb-meetingtechnology directaccesstosharedrequirementsmodelsviaacentralserver automatedgenerationoftestsandreviewingtheseinconcertwiththerequirementstoproveanother

perspectiveofwhattheproductneedstoprovide.

CONCLUSION

Have you heard that England is changing their trac system to drive on the right-hand side o the road?But to ease the transition theyve decided to phase it in - rst, theyll start with trucks.

A common mistake o development organizations making the shit rom waterall to agile is that theirorganization still mandates they still produce their big, heavy set o documents and have them reviewed atthe same milestones, clinging to these amiliar assets like security blankets. It doesnt work. As scary as it

might seem all signicant aspects o the approach, like documentation, need to change in unison i its to besuccessul, and Requirements are one o those signicant aspects.


12/13


However i you still want that security blanket and you want to have some benet o agile, at least generate

your requirements specication in an agile manner (iterative, evolutionary, time boxed, customer driver,adaptive planning) that includes simulations integrated and driven by use cases traced to eature. This is oneway to reap some agile benets without making the leap all at once.

Risk is the enemy on sotware projects. High risk proles on projects drive uncertainty, render estimatesinaccurate, and can upset the best o plans. One o the great things about agile is that its highly iterativenature continually turns over the rocks to expose risk early and oten so it can be dealt with.

On the other hand, one o the great challenges or larger and distributed teams is keeping everyone alignedas course-corrections happen sprint by sprint. A big part o this is the time and eort it takes to produce

and update assets and the delays caused by imperect and strained communication. The good news isthat tools and technologies now exist to produce many o the assets automatically and to also dramatically

improve communication eectiveness, allowing agile to scale.

With the right approach, techniques and technology, distributed agile can be done. Weve done it. So canyou.

REFERENCES

TheScrumAlliancehttp://www.scrumalliance.org/

ApproachestoDeningRequirementswithinAgileTeamsMartinCrisp,Retrieved21Feb2009fromSearchSoftwareQuality,http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1310960,00.html

BeyondFunctionalRequirementsonAgileProjectsScottAmbler,Retrieved22Feb2009fromDr.DobbsPortal,www.ddj.com/architect/196603549

AgileRequirementsModelingScottAmbler,Retrieved22Feb2009fromAgileModeling,http://www.agilemodeling.com/essays/agileRequirements.htm

10KeyPrinciplesofAgileSoftwareDevelopmentRetrieved22Feb2009fromAllAboutAgile,http://www.agile-software-development.com/2007/02/10-things-you-need-to-know-about-agile.html

AgileRequirementsMethodsDeanLefngwell,July2002,TheRationalEdge

RequirementsHonestyFranciscoA.C.Pinheiro,UniversidadedeBrasilia

RequirementsDocumentsthatWintheRaceKirstinKohler&BarbaraPaech,FraunhoferIESE,Germany

EngineeringofUnstableRequirementsusingAgileMethodsJamesE.Tomayko,CarnegieMellonUniversity


13/13


ComplementingXPwithRequirementsNegotiationPaulGrunbacher&ChristianHofer,JohannesKeplerUniversity,Austria

JustinTimeRequirementsAnalysisTheEnginethatDrivesthePlanningGameMichaelLee,KuveraEnterpriseSolutionsInc.,Boulder,CO.