For those of you that don't know, I am currently the software development manager for a fortune 500 financial company in the United States. Because I work in the financial industry most agile coaches are shocked that we even practice agile development. Most financial institutions are set in their ways when it comes to developing software. Usually it is the traditional waterfall (BDUF) process that plagues these institutions.
The most important aspect of introducing agile practices is to make sure to include everyone. By everyone I mean every stake holder. Usually in a large corporation you have business analyst who act as advocates for the customers in the field. Then you have systems analysts who act as proxies between the development team and the business analyst. Then you finally have the development team who actually builds the system. When introducing agile you have to make certain not to exclude or take away from given responsibilities that have been there long before you came along.
The information below is the beginning of a 6 part series on corporate agile development.
Corporate Agile Development Life Cycle Stage Overview
Corporate Agile Development supports rapid iterative development with continuous learning and refinement. Product definition, development, and testing occur in the form of six phases resulting in the incremental completion of the project. These six phases form the foundation of a release. Different releases have different focus as the project approaches completion. One week iterations allow you to reduce the margin of error in your estimates and provide fast feedback about the accuracy of your project plans. The following list and illustration provide an overview of the process. The subsequent chapter will provide more guidance on how each phase is implemented.
Six phases of a release:
- Storming Phase
- Planning Phase
- Development Iteration Phase
- System Integration Testing (SIT) Phase
- User Acceptance Testing (UAT) Phase
- Closing Phase
The entire process is geared around collaboration and communication. Subtle variations have been added to expand upon on already proven process.
While in general practice agile methodologies encourage change and adaptation, certain changes have greater impact and require careful consideration and coordination. It is not a matter of control—who gets to make the decisions—as much as it is a matter of coordination—making sure the team understands the total impact of a change and which groups are affected. The Business Analyst partner along with the Systems Analyst and Development Architects collaborate around requirement goals. The result of this partnership is the determination jointly if the requirement goals are viable enough to make it into a release planning phase.
The purpose of the storming phase is to clearly identify what is to be modeled and to uncover any user goals that require additional information. The following artifacts will be the result of the storming phase:
- Field Request
- Requirement Goals
- Feature Cards
- Feature Skeleton
- Planning Preparation Meeting
It is not a matter of control—who gets to make the decisions—as much as it is a matter of coordination—making sure the team understands the total impact of a change and which groups are affected. The Business Analyst partner along with the Systems Analyst and Development Architects collaborate around requirement goals. The result of this partnership is the determination jointly if the requirement goals are viable enough to make it into a release planning phase.
The purpose of the storming phase is to clearly identify what is to be modeled and to uncover any user goals that require additional information. The following artifacts will be the result of the storming phase:
What is a Field Request
Every day new ideas or concepts for a system are brainstormed or thought of. These epiphanies lead to enhancement to an existing systems or the creation of an entirely new system. A field request is nothing more than the culmination of these epiphanies manifested in a written, auditory or electronic medium.
The Business Analysts are responsible for aggregating the entire queue of field request for their customers. The queue should be prioritized from a business value perspective that allows the Business Analyst manager to quickly determine what field request warrant further investigation in becoming a Requirement Goal.
Field User Sally: (Drafting and short email)
I was wondering if you could please find a way for our clients to use some type of machine to draft money from their account and see their balances.
Thank you,
User Sally
It seems so easy to think that if everything is written down and agreed to then there can be no disagreements, developers will know exactly what to build, testers will know exactly how to test Customers will get the developers' interpretation of what was written down, which may not be exactly what they wanted.
Before we talk about what a requirement goal is let’s talk about what it isn’t.
The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications (IEEE 1998). This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830-style software requirements specification is the use of the phrase "The system shall..." which is the IEEE's recommended way to write functional requirements. A typical fragment of an IEEE 830 specification looks similar to the following:
4.6) The system shall allow a company to pay for a job posting with a credit card.
4.6.1) The system shall accept Visa, MasterCard and American Express cards.
4.6.2) The system shall charge the credit card before the job posting is placed on the site.
4.6.3) The system shall give the user a unique confirmation number.
Documenting a system's requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique. However, if you're dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it is not going to be thoroughly read by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.
Unfortunately, it is effectively impossible to write all of a system's requirements this way. There is a powerful and important feedback loop that occurs when users see the software being built for them. When users see the software, they will come up with new ideas and change their minds about old ideas. When changes are requested to the software described in a requirements specification, we've become accustomed to calling it a "change of scope." This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. It doesn't matter how much effort is put into upfront thinking about requirements, we've learned that users will have different (and better) opinions once they see the software. Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills its intended users' goals. If the scope of the user's goals changes then perhaps we can speak of a "change of scope," but the term is usually applied even when it is only the details of a specific software solution that have changed.
IEEE 830-style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user's goals. Lists of requirements do not give the reader the same overall understanding of a product that stories do. It is very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll (2000) suggests that designers "may produce a solution for only the first few requirements they encounter." For example, consider the following requirements:
3.4) The product shall have a gasoline-powered engine.
3.5) The product shall have four wheels.
3.5.1) The product shall have a rubber tire mounted to each wheel.
3.6) The product shall have a steering wheel.
3.7) The product shall have a steel body.
Now imagine in your mind what type of vehicle this is and what it looks like. Is it red? How big are the tires? How fast does it go?
But suppose that instead of writing an IEEE 830-style requirements specification, the user told us their goals for the product:
As a landscaper I would like a product that makes it easy and fast for me to mow my lawn. I want to be comfortable while using the product.
By looking at the user's goals, we get a completely different view of the product and realize that the customer really wants a riding lawn mower, not an automobile or what ever else you imagined. These goals are not user stories, but where IEEE 830 documents are a list of requirements, requirement goals describe a user's goals. By focusing on the user's goals for the new product, rather than a list of attributes of the new product, we are able to design a better solution to the user's needs.
A final difference between user stories and IEEE 830-style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written down. The typical scenario is that one or more analysts spend two or three months (often longer) writing a lengthy requirements document. This is then handed to the programmers who tell the analysts (who relay the message to the customer) that the project will take twenty-four months, rather than the six months they had hoped for. In this case, time was wasted writing the three-fourths of the document that the team won't have time to develop, and more time will be wasted as the developers, analysts and customer iterate over which functionality can be developed in time. With requirement goals, an estimate is associated with each story right up front. The customer knows the velocity of the team and the story unit cost of each story. After writing enough stories to fill all the iterations, they know when they are done.
To help author a requirement goal please consider the following template.
|
Requirement Goal |
|
Date {Insert Date}
Desired Implementation Date {Insert Date}
Business Analyst {Business analyst name}
Executive Sponsorship {Executive name and title}
Goals
{User role} would like {feature(s)}, this {feature} should be able to {action}, when implementing this {action} please check {criteria}
Benefit
By implementing this {feature} the business will be able to {introduce business value}
Detriment
If we fail to implement {feature} the business will {introduce risk of failure to implement} |
|
Example:
Date 01/01/2007
Desired Implementation Date 04/01/2007
Business Analyst Susie Que
Executive Sponsorship Jack Marshal Regional Director
Goals:
The user would like to log into the ATM by first swiping their personal ATM card issued from the branch office and then key in a 4 digit PIN. When the user creates their pin we have to make certain that their pin does not match the last 4 digits of their SSN that we have in the system.
After the user logs into the ATM they should be presented with a home screen that displays a welcome message and their name. The client should then be able to see a menu list with the following options.
• Balance Inquiry
• Withdrawal
• Transfer
Benefit:
By implement ATM machines in our branches our company will be able to offer a competitive advantage over our competitors.
Detriment:
If we fail to implement ATM machines in our branches our company will be forced to stay open till 10 PM increasing resource cost by 35% nationwide.
|
The Business Analysts are responsible for authoring of a Requirement goal. If you refer to the field request section of this document you will notice that a field request does not always have a sufficient amount of detail to author a requirement goal. The business analyst will sometimes have to perform additional analysis to work toward drafting a more thorough requirement.
NOTE: The goal of the requirement goal is just that to convey a purpose. At no time should the requirement goal be treated as a concrete contract between ILS and the business. It is merely serves as a medium to convey information that helps in the creation of feature cards later in the process. During the feature card creation additional details may be uncovered that will require the business analyst to update the requirement goal.
Discussion is critical to understanding, which in turn is critical to estimating. Features cards are used to identify and define features at a high level. Feature cards act as concords between product owners and project team members to discuss (and document, to the extent necessary) detail elemental data that can be later formulated into stories that are subsequently scheduled into iterations. Feature cards identify features that the product owner would desire to have in the product.
The purpose of feature cards is to provide a simple medium for gathering basic information about application or system specific features being requested from the business goals. This channel is intended to be a central conduit for all ILS activities to revolve around.
Feature cards are comprised of the following key items of information:
- Identifier: an alphanumeric or numeric identifier that serves as a unique identifier for the feature.
- Name: a short name or description of the feature
- Summary: a paragraph or two describing high level functionality and modules that may comprise this feature
- Type: C = customer domain, T = technology domain
- Customer domain – The customer domain are features that originate from the product owners of the project usually governed by more formal requirement documents.
- Technology domain – The technology domain are features that originate from the development group or systems analyst within the ILS department.
- Estimated work effort: Aggregate of the following factors
- Estimated work effort for requirements gathering
- Estimated work effort for wire frame design
- Estimated work effort for coding and unit testing
- Estimated work effort for testing
- Estimated work effort for documentation
- Estimated work effort for reporting
- Planning Complexity: This is a weighted measurement to determine the resource allocation and duration that the feature will require during a planning week.
- High – 8 hours of planning time. One entire day is needed to break down the feature into a model and relative stories.
- Medium – 4 hours of planning time. Half a day is needed to break down the feature into a model and relative stories.
- Low – 2 hours of planning time.
- Requirements uncertainty (erratic, variable, regular, stable): an “exploration factor” for a specific feature. The requirements uncertainty is a subjective weight that is explored by both the Systems and Business Analyst to determine the viability of the feature being presented during a release planning session. The matrix below details the guidelines that can be used to determine the maturity of requirement being requested.
Requirement Uncertainty Guidelines
Erratic
- The requirement contains minimal information and the contents remain in an erratic state where business owners and field stakeholder cannot agree on the concept or idea that is being presented.
- Executive sponsorship has not been approved
Variable
- The requirements contain more information than the erratic state
- There may still be outstanding variables that are still in question as to how the requirement should function when integrated into the system.
- A screen skeleton has been presented (if applicable)
- Executive sponsorship has not been approved
Regular (can be scheduled during a release planning week)
- The requirements may contain more information than the variable state
- The general requirement concept or idea is understood and can be talked to in a group setting to finalize greater details
- A screen skeleton has been presented and general concepts annotated (If applicable)
- Executive sponsorship has been approved
Stable (can be scheduled during a release planning week)
- The requirements have been completely documented
- All ideas and concepts are thoroughly understood and can be easily communicated in a written and verbal medium
- The screen skeleton has evolved to a more thoroughly documented wire frame that explicit details or references business rules
- Executive sponsorship has been approved
- Dependencies: A list of other external dependencies that could influence implementation sequencing.
NOTE: You should strive to get the feature to a state where it can exist on its own without having a dependency on other features. Dependency on other features should be an exception a not a rule.
- User Acceptance Tests: Criteria the product owner will use to accept or reject the feature
NOTE: It is important not to confuse feature cards with stories. The details captured in the feature cards serve as a launching pad for future planning sessions that uncover customer stories that can be instituted into release iterations. The feature cards form a conduit for all information to flow through and are weighted against the Requirement Goal.
A features behavior is simply its acceptance criteria – if the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t.
Describe the acceptance criterion in terms of scenarios, which take the following form: Influenced by Dan North
Given some initial context (the givens),
When an event occurs,
Then ensure some outcomes.
This is a (Positive, Negative, Dimensional) aspect.
The aspect of the acceptance test helps to discern the overall test coverage that the feature has. It is important to touch on at least two different aspects for every feature.
To illustrate, let’s use the classic example of an ATM machine. One of the requirement goals might look like this:
Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.
So how do we know when we have delivered this feature? There are several scenarios to consider: the account may be in credit, the account may be overdrawn but within the overdraft limit, the account may be overdrawn beyond the overdraft limit. Of course, there will be other scenarios, such as if the account is in credit but this withdrawal makes it overdrawn, or if the dispenser has insufficient cash.
Using the given-when-then template, the first two scenarios might look like this:
Scenario 1: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
This is a positive aspect
Notice the use of “and” to connect multiple givens or multiple outcomes in a natural way.
Scenario 2: Account is overdrawn past the overdraft limit
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returned
This is a negative aspect
Both scenarios are based on the same event and even have some givens and outcomes in common. We want to capitalize on this by reusing givens, events, and outcomes.
The following is an example of a feature card based on the previous requirement goal.
|
Requirement Goal |
|
Example:
Date 01/01/2007
Desired Implementation Date 04/01/2007
Business Analyst Susie Que
Executive Sponsorship Jack Marshal, Regional Director
Goals:
The user would like to log into the ATM by first swiping their personal ATM card issued from the branch office and then key in a 4 digit PIN. When the user creates their pin we have to make certain that their pin does not match the last 4 digits of their SSN that we have in the system. If the PIN does not match then store the PIN in the system and associate it with the ATM card. If it does match then display an error message with the following text “You may not use a PIN that matches the last 4 numbers of your social security number"
After the user logs into the ATM they should be presented with a home screen that displays a welcome message and their name. The client should then be able to see a menu list with the following options.
• Balance Inquiry
• Withdrawal
• Transfer
Benefit:
By implement ATM machines in our branches our company will be able to offer a competitive advantage over our competitors.
Detriment:
If we fail to implement ATM machines in our branches our company will be forced to stay open till 10 PM increasing resource cost by 35% nationwide.
|
|
Feature Card |
|
Card No: 052205
Name: Branch 4 Digit PIN number creation
Summary: The client will create a 4 digit pin number in the branch.
Type: Customer
Requirements Uncertainty (erratic, variable, regular, stable): Regular
Dependencies: None
User Acceptance Tests:
Given that the client is creating a 4 digit PIN number
When the client has keyed in a 4 digit pin that does not match the last 4 digits of their SSN
Then the PIN is stored in the clients account profile.
This is a Positive aspect
Given that the client is creating a 4 digit PIN number
When the client has keyed in a 4 digit pin that does match the last 4 digits of their SSN
Then the client is presented with an error containing the text “You may not use a PIN that matches the last 4 numbers of your social security number”.
This is a Negative aspect
|
|
Feature Card |
|
Card No: 052206
Name: Welcome Screen
Summary: After the user is authenticated to the system they should be presented with a welcome screen
Type: Customer
Requirements Uncertainty (erratic, variable, regular, stable): Regular
Dependencies: 052207
User Acceptance Tests:
Given the user has just left the login screen
And they are authenticated
When the welcome screen is presented
Then the welcome message on the screen should be presented
And the user’s full name be presented in the following format {first name} {mi} {last name}
And a menu list be displayed with the following options: Balance Inquiry, Withdrawal, Transfer
This is a Positive aspect |
|
Feature Card |
|
Card No: 052207
Name: Login Screen
Summary: The client would like to log into the system using a login screen
Type: Customer
Requirements Uncertainty (erratic, variable, regular, stable): Regular
Dependencies: 052205
User Acceptance Tests:
Given the user trying to log into the ATM
When the user swipes his ATM card
And the user inputs the correct PIN
Then the system should log the time the user logged in
And the screen should go to the welcome screen
This is a Positive aspect
Given the user trying to log into the ATM
When the user swipes his ATM card
And the user inputs the incorrect PIN
Then the login screen should display the following message “The PIN is incorrect, please try again”
This is a Negative aspect
Given the user trying to log into the ATM
When the user swipes his ATM card incorrectly for the 3rd time
Then the login screen should display the following message “Your card is no longer active, please call 1800-555-5555”
And the system should lock the account ATM privileges
This is a Dimensional aspect |
The Systems Analysts are responsible for authoring of a Feature cards. While the systems analysts are responsible for authoring the feature this engagement must not be done in vacuum. It is critical that the documentation of the feature be agreed upon by business and all other stakeholders. Remember all artifacts in the ILS software development lifecycle are living documents and are subject to change at any time pending the appropriate stakeholders all agree on the changes.
Sometimes requirement goals may not capture the idea or concept that the business is trying to convey. Often a simpler medium of communication may be a sketch, diagram or picture. Pictures often speak volumes of information over written text. It is imperative that everyone understand that these forms of communication are acceptable at conveying an idea. Often the greatest ideas are thought of over lunch and quickly jotted down on a napkin. Let’s not limit creativity or the medium that it is conveyed in.
The purpose of screen skeletons is to provide a simple pictorial representation of the intended layout of how the requirement goal should take form as a graphical user interface. The screen skeleton will later be used as that foundation for the more detailed wire frame that is the result of a planning week.
This is a rather crude example of a screen skeleton but shows to reason what can be used as a screen skeleton.
{Figure 4: Screen Skeleton }
The Business Analysts are responsible for the creation of the screen skeletons.
NOTE: The screen skeletons are one of the optional artifacts of the ASDLC. They are not required in order to call a requirement goal complete.
The final activity of the storming phase is preparing for the planning phase. To facilitate this goal the planning preparation meeting takes place.
This meeting is designed to be a collaborative engagement between the business analyst, systems analyst and development architects. The planning preparation meeting results in a schedule of events for the planning phase. This schedule will contain modeling session engagement and resources that have been assigned to each session.
Each feature card contains a “planning complexity” rating. This rating of High, Medium or Low are used determine the amount of time that will be required to adequately model and understand the business feature.
The figure below depicts a simple illustration of a planning meeting. A typical modeling team consists of five stake holders: one Modeler, one business analysts, one systems analyst and two developers. Utilizing everything we have done with the feature cards during the storming phase we will now use the planning complexity rating in conjunction with the dependency field to determine how we should plan the week.
Considering that the “Branch 4 digit PIN # creation” feature as at the top of the dependency tree it make logical sense to start with this feature first. You will notice that the planning complexity rating is a HIGH for this feature. This is a quick indication that the probability of this story lasting all day is great. Therefore we should not schedule any other features for this modeling team for the remainder of that day. The “Login Screen” and “Welcome Screen” planning complexity rating are MEDIUM. Since the medium rating tells us that this modeling session should last know longer than four hours, we can easily place both these stories into the next day and lower the risk of over taxing the modeling team.
The Business Analysts are responsible for the final schedule of the Planning Phase. The Systems Analyst are responsible for scheduling the Planning preparation meeting.
The next post will be on the Planning Phase.