Skip to main content

Building and Managing a Requirements Center of Excellence. Part I.

Written by Tony Higgins on . Posted in Articles.

Maximize Application Quality; Minimize Cost and Time-to-market.

The phrase “the world runs on software” is almost cliché now. Everyone’s life is a daily testament to this adage. Software is ubiquitous and is without question business critical. Virtually every modern-day business has some, if not all, of their business-critical functions implemented in software. In the software game, if you “get it right” the benefits of implementing business in software can be tremendous. If you don’t “get it right” you can find yourself out of business.

Errors in a software development projects have to be confronted if you are to deliver a product with any degree of quality – it isn’t a matter of “if” you fix them, it’s a matter of “when”. Most errors in a software development project originate very early in a project during requirements definition – 68% in fact [Standish]. This represents a huge opportunity to improve software project performance since it is well known that errors are exponentially cheaper to fix when detected earlier in the development life-cycle. But how do we find errors at this early stage and/or prevent them altogether? How do we unambiguously communicate the requirements to developers, testers, and support personnel in a language they understand? Once these questions are answered, how then do we make this a core-competency of our software development capability across all projects? This is what a Requirements Center of Excellence (CoE) is intended to address. It is an investment to capitalize on what is one of the largest opportunities related to software development, and therefore business, today.

In short, a Requirements CoE is the consolidation and centralization of Requirements expertise, knowledge, process, and tools, so that it may be continually improved and leveraged to maximum advantage across all projects in an organization. With a Requirements CoE, valuable new lessons from one project, instead of taking months or years to propagate “organically” can be quickly leveraged across the organization thereby driving rapid improvement.

Just some of the benefits from implementing a Requirements CoE include:

Cost Savings. Early error detection and correction dramatically reduces rework

Efficiencies. Consolidation of disparate requirements initiatives

Reduced Time to Market. Reduced rework results in finished products sooner

Product Predictability. Early error detection reduces risk, improving predictability

Quality. Higher quality requirements and automatically generated inputs for Developers and Testers means less rework and higher quality results

Rapid Improvement. Requirements investments are leveraged across the organization much faster

One of the most promising aspects of a Requirements CoE is that it allows for consistent measuring performance from the perspective of business and end-user results across the organization – not just measuring systems and components at a project or departmental level. With all projects addressing requirements with a consistent approach, common metrics can be established and directly related to business objectives.

A Requirements CoE can be built incrementally with return on investment measured at every stage. For the more risk-averse you can start small, consolidating and leveraging existing requirements resources, and expand as the value is proven.

A Requirements CoE can dramatically reduce the cost of software development for the organization and provides mechanisms to make the benefits sustainable.

What is a Requirements Development Center of Excellence?

A Requirements CoE is an internal group focused on optimizing the quality of requirements produced for all software development projects, ensuring that the requirements reflect true business needs and that they can provide the basis for efficient and effective product development.

The types of activities a Requirements CoE performs include:

  • Requirements tool evaluation, standardization, purchase for the organization
  • Requirements process definition, standardization, and tailoring
  • Requirements Metrics definition, automation, collection, storage, reporting
  • Requirements Training and mentoring services for company staff
  • Project “Startup” services (assess, recommend tools, process, training, mentoring)
  • Requirements component reuse storage, repository, cataloguing, and guidance
  • Requirements model review and consulting services for projects
  • Requirements guidelines, standards, and best practices
  • Representation in industry Requirements community

    (a more comprehensive list is provided later in this article)

Through the Requirements CoE approach, project teams are able to take advantage of all of the expertise, process, toolsets, and best practices the Requirements CoE has developed and consolidated. This section provides an overview of the Requirements CoE and examples of the services it can provide. The next section takes a closer look at the business value of implementing a Quality CoE

Traditionally every project team is an island with its own staff, tools, and practices. The Requirements CoE model centralizes the expertise and processes, brings Key Performance Indicators (KPIs) to requirements initiatives, and can actually reduce total headcount needed to develop, test, and deliver higher quality applications.

Checklist:

You Should Transition to the Requirements CoE Model soon if you have

  • Chronic overruns of project budget or schedule, or regularly change scope of application to meet targets
  • Inability to estimate the cost and schedule impacts of proposed changes during development
  • Different approaches to expressing requirements from project to project
  • Project success seemingly dependent on involvement of a few key individuals
  • No perceptible improvement in predictability of projects from one to the next
  • Applications that are difficult to modify or customize, and expensive to maintain
  • Incomplete or inaccurate technical documentation for an application

How a Requirements CoE works: Five Simple Examples

The examples below contrast how an organization might respond to real-world situations with and without a Requirements CoE.

Example 1: A key employee with several years’ experience in business analysis leaves the company mid-way through a critical project

  • With a Requirements CoE.: The company’s best practices for Requirements Development are defined and shared through the Center of Excellence. All Requirements Center models and sub-models developed by the Analyst over the years are immediately available from the Requirements repository maintained by the Requirements CoE. The Requirements CoE can provide short-term relief to the current project with Business Analysis skills, and/or help ramp up a replacement with any training and mentoring that may be required.
  • Without a Requirements CoE. The project scrambles to find a replacement and then ramp up that replacement on the manner in which this project works with requirements. Information, notes, emails, and any other bits of information found are gathered in an attempt to reconstruct requirements in their current state. Co-workers and past colleagues are polled to find historical knowledge from the employee.

Example 2: Acquire a Company

  • With a Requirements CoE. All projects of the “host” company develop requirements in a consistent and effective fashion in accordance with the company’s best practices for Requirements Development as defined and shared through the CoE. CoE experts assess the acquired company’s Requirements Development capabilities and make recommendations for transition and any modification to existing assets (eg. Project Start-up packages, courses, packaged services, etc.). Training and mentoring packages of the CoE are used as part of a transition plan to educate staff of the acquired company. Project Start-up packages, maintained and delivered by the CoE, are used to launch new projects within the acquired company or as a basis to plan transition of projects in progress, where appropriate. A focused transition with well-defined “end-state” where all expectations of host and acquired staff can be managed effectively. Acquired staff gets a sense they are transitioning to a well-managed environment.
  • Without a Requirements CoE. Host organization differs in Requirements Development approach from project to project, with low level of consistency. Not clear what acquired company should transition to, if to transition at all. Result is perpetuating acquired company’s requirements approach thereby creating yet another “stovepipe” in the organization, inhibiting integration of the acquired company and the efficiencies that should have been gained because of it. With no clear “end-state” for the requirements discipline the expectations of acquired staff are difficult to manage and they lack a sense of moving to something better. Instead they have a sense of being assimilated into a chaotic environment. Morale diminishes among the acquired staff increasing turnover, reducing productivity, and increasing risk of failed acquisition.

Example 3: External party (customer, prospect) to review or audit software development capability.

  • With a Requirements CoE. Requirements Development process including best-practices, sample artefacts, templates, guidelines are maintained by the Requirements CoE and made accessible to all projects. Project performance measures collected analyzed and reported on by the CoE are also available. Any mappings of adherence to industry models (CMMi, ISO, etc.) are also be maintained by the CoE. All this information is available for review by the external party and can be explained and discussed with experts from the CoE. Projects in progress can be shown to adhere to the standard process and any can be chosen as an example for further examination.
  • Without a Requirements CoE. An effort is launched to canvas projects seeking the “nicest” examples of requirements artifacts. Any process descriptions are similarly gathered or created in order to explain how requirements activities are performed. Directories for old projects are scanned, again seeking good examples of requirements artifacts. Metrics on performance are gathered where they exist, and attempts made to normalize and reconcile them in order to extract some meaning.

Example 4: A new, business-critical project initiative is being considered and accurate estimates of time and cost are required in order to make a decision to proceed.

  • With a Requirements CoE. Requirements models for past projects in the repository are examined for reusable models and sub models. Metrics on past project performance are analyzed. A high level, abstract Requirements Center model is created and supplemented with any reusable sub-models found. This model, along with performance metrics gathered, is used as key basis for estimating the new initiative.
  • Without a Requirements CoE. Pull most knowledgeable, senior people from current assignments together and collect subjective impressions from past projects of similar nature, magnitude and complexity, if they exist. Estimate for new initiative is based on these impressions and personal experience.

Example 5: A new project is being launched, and the “environment” consisting of process and tools needs to be established.

  • With a Requirements CoE. The Project Manager notifies the CoE of the new project. Experts from the Requirements CoE deploy the “Project Start-up” packaged service. They assess the project to deduce best fit, given project type, complexity, duration, budgets, people, etc. CoE experts deliver training and mentoring, deploy and configure the toolset, and put process in place. The CoE experts assist with project launch and deliver mentoring with emphasis during early stages of Requirements Development, ensuring staff are proficient with process and tools. Initial artifacts are reviewed by CoE experts to help staff converge on the optimal solution. CoE experts are involved in every major project review and are on call to provide “Just in Time” mentoring and assistance. CoE experts liaise with tools manufacturers as “single point of contact” for special requests and support on behalf of all projects.
  • Without a Requirements CoE. The Project Manager tries to secure time with process “experts” from wherever they may be in the company. Experts and senior project staff do “process engineering”, typically under project budget, to identify desired approaches, tools, templates, guidelines, etc. for the project. The results of this activity are highly dependent on the personal experience of the individuals involved. The project then puts all in place, must devise means of educating staff, acquires and deploys/configures tool(s). Interfacing with vendor is often done by designated project staff. When issues arise with process, tools, advice is sought in informal manner from whatever source might be available.

Start Small and Grow Organically

One of the key advantages of a Requirements CoE is that it can be established incrementally and show incremental returns on investment. A Requirements CoE can be built on a small scale initially with minimal capital expenditure and you can scale up its resources, services, and capabilities incrementally as its value is proven.

Initially the Requirements CoE could focus on the standardization of requirements artifacts including notations and formats. This can be followed by, or deployed in conjunction with, standardization of tool support for defining requirements. In time, the process by which requirements are developed based on the notations and automation can be formalized and tuned. The standardized process would include aspects made possible only by automated tool support, such as immediate validation of requirements using simulation and testability assurance. Still later a centralized repository for requirements artifacts to facilitate reuse could be added followed by a formal requirements metrics program to provide the basis for continual requirements improvement.

Therefore the CoE can grow both in capability and breadth of adoption across the enterprise at a rate that fits the constraints of the organization.

Requirements CoE Resources and Services

The Requirements CoE has the potential to become a competitive advantage for any company whose business relies on software. Since requirements are the cornerstone of the software development process with all other disciplines dependent on its artifacts and with 68% of all errors being introduced at this point, there is tremendous potential for cost-savings and quality improvement. The nature of the services that can be provided by a Requirements CoE include:

“Project Start-up” Services with Respect to Requirements

  • Leverage the growing Requirements Development knowledge and experience base
  • Provide expert assistance in assessing and devising best approach for tools, process, and training/mentoring needs for the project
  • Assist in setting up environment including project guidelines, standards, templates, and other assets
  • Deliver training and mentoring in Requirements Development process and tools

To be a Cross-product/divisional “Communication Hub” for Requirements

  • “harvest” business assets and make reusable
    • Business cases and studies to make it easier for other divisions to adopt
  • “harvest” technical assets and make reusable
    • Best practices in Requirements Development across projects
    • Reusable Requirements components
    • Reusable Requirements Training components
  • Establish mechanisms to foster communication in Requirements Development
    • Newsletters, bulletin boards, interest-group meetings

Requirements Development Tool Expertise

  • Single point of liaison with Requirements Development tool vendor. Promote organization’s interests, enhancement management, beta participation
  • First-line support for Requirements Development tool
  • Experts in tool configuration for specific project usage and application
  • Development of, and repository for examples templates that support process
  • Best Practices in tool usage for specific applications

Requirements Development Process Expertise

  • Generation and maintenance of standard Requirements Development process
  • Expertise to tailor and adapt the standard process to suit specific projects
  • Collection of empirical data and metrics to facilitate continual process improvement
  • Expertise to teach and mentor project staff in Requirements Development process

Education and Awareness of Requirements Development to the Larger Organization

  • In early stages this new discipline will be largely unknown to most. This center should be capable of fielding requests for information and providing introductory education
  • Should also be in a position to deliver demonstrations, learning sessions, and similar as part of awareness efforts

To Liaise with Industry Associations and Represent the Organization in these Forums

  • In order to “harvest” best-practices and approaches found by others, and to monitor trends in the discipline
  • In order to contribute organizational learning

To provide these services the Requirements CoE should maintain a core staff, whose levels will depend upon how aggressively the organization chooses to grow the discipline. Initially this could involve a part-time manager and single domain expert but could scale over time to support an enterprise.

In this article, we have discussed what a Requirements CoE, is and how it works. Stay tuned for next issue’s follow up, on why organizations should adopt a Requirements CoE, and step-by-step lessons on how to build one.

Don’t forget to leave your comments below

Tony Higgins is Vice-President of Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst. Tony can be reached at [email protected].

No Where to Hide, Suckas!

Written by Marcos Ferrer on . Posted in Articles.

When I speak with many BAs, we laugh and agree that there is nothing more detestable than politics. We have seen SO MANY bad “ego” or “fear” based decisions instead of “fact” or “opportunity” based decisions that we rightly do not admire what people call politics.

For those who want to explore the full depth of “political evil”, I offer the following link – http://the-redpill.blogspot.com/2009/04/art-of-politics-10-methods-to-obfuscate.html – not very scholarly, but very illuminating. This article is a pretty good summation of the forces resisting positive change, and the sorts of dirty tricks that many use.

For those who want to know what to do about negative politics, I say simply – become a master positive politician, or hook up with one (a master political act in its own right!).

Even as an amateur politician, I have enjoyed huge (in spite of high risk and low probability) successes. Now I realize that no one can be a senior BA without practicing politics. If you think you can, it only means that you are merely a technician (not a leader) OR you have a master politician backing you and you don’t even know it – wake up!

I leave the “dirty tricks” to others – let’s look at the “clean tricks” in politics.

The essence of politics (and human society) is STORY. Become a storyteller, give people a plot, a crisis, a villain, a hero and a twist and climax to strive for.

Political Clean Trick # 1

The best I ever participated in was a huge COBOL to on-line real time system conversion (the name of the client remains mine to know, of course). In spite of the fact that the employees of the client spent vast amounts of time writing duplicate data in forms, instead of doing their primary jobs (finding significant data), the employee’s union was dead set against the new system. This had gone on for years (don’t laugh – the client bought a new phone switch, and the union forced them to store it for four years during negotiations on its use).

The “plot” of the story that was used was quite brilliant – the COBOL system must be replaced, because of Y2K (the crisis). The villain was the stupidity of technology itself.

The “heroes” were the employees, who knew best, and would be allowed to continue filling out paper forms – just like daddy and mommy did – and would not be required to use he new system (a $15,000,000 investment, by the way).

The twist was that, since the employees knew best, we engaged a number of the best employees in advising us about the requirements for any new system (darnnY2K, what are you gonna do?), and we made sure that they saw ALL developing screens, and that their input was eagerly engaged, and a majority of their suggestions were implemented.

The climax was (and this was planned all along, and much supported by management, the true powers in the process) that the new system was so excellent, and so fun, and so productive for the employees (unlike the old system), that even though they were not required to use it, they just wanted to.

Again, without force, the employees (especially early adopters, who got promotions, lots of attention, and/or improved duties if they wanted them) were the heroes.

After three years of the new system, the employee’s union agreed that it was a fait accompli, and a desirable addition to their profession, and that they would not fight it anymore. The last “non-users” of the new system retired several years ago, and now if you try to change the new system, people complain.

Political Clean Trick # 2

Hey, 500 words at a time! This is only a blog, and free besides J.

If you really want to know, what’s it worth to you? Is it worth enough to read this blog next month? Is it worth enough to question your attitude about politics, and learn something different? Is it worth enough to tell us one of your own stories, in return for picking my brain? I promise if you stay tuned, that # 2 is worth its wait in gold.

Have fun, and I look forward to your questions and comments.

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. While still a student at the University of Chicago, he developed a consulting practice with local property management and accounting firms. Following graduation in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. In 1990, Mr. Ferrer became an independent consultant, again working with a variety of clients in the family entertainment industry and then for 10 years at the U.S. Department of Labor, converting legacy COBOL systems into real time client server systems. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer became one of the first 18 CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

Beyond Requirements Analysis – Enterprise Analysis

Written by Alan S Koch on . Posted in Articles. 1 Comment on Beyond Requirements Analysis – Enterprise Analysis

“What do your Business Analysts do?”

“They develop and manage project requirements, of course. What else would they do?”

What else indeed!

The BA Body of Knowledge (BABOK®) defines what a professional BA should know and do. Much of it is focused on requirements work – but not all. One of the knowledge areas that takes the BA beyond requirements work is “Enterprise Analysis.”

Enterprise Analysis (EA) encompasses those activities that the job title “Business Analyst” actually points toward: analyzing business processes. The majority of these activities is outside of projects, and in fact, put the BA into the position of recommending and justifying projects.

Enterprise Analysis

Analyzing business processes is indeed a big part of what we do during Requirements Analysis. But that is not the only context where this analysis should be done, and in fact, it is not the most valuable time to do it. In the Enterprise Analysis knowledge area, the BABOK identifies several other contexts in which such analysis should be done.

Activity: Creating and Maintaining the Business Architecture

As the name of this activity implies, “Creating and Maintaining the Business Architecture” is an on-going activity that has as its focus the entire enterprise. The “Business Architecture” is a model of all the business processes that are used throughout the enterprise. It shows how they work and relate to each other.

The net result of this is an understanding that most organizations lack, of how all their moving parts mesh with each other. This broad understanding of the enterprise’s processes becomes the foundation for all of the other responsibilities of the BA. But its bigger value comes in providing every member of the organization with a clear understanding of how his or her department and individual job fits into the bigger picture

Recommending and Justifying Projects

The bulk of the activities described in the Enterprise Analysis knowledge area center around proposing and justifying projects. These are activities that occur in some form or other in any organization. But with the BA’s involvement, they can provide much more value and ensure the organization’s resources are spent on the most valuable projects.

Activity: Conducting Feasibility Studies

Projects are created to solve a problem or to take advantage of an opportunity. It is rare for there to be only one available solution to a problem or opportunity, so part of project initiation involves exploring the alternatives. The BA can provide a valuable service by calling upon his or her understanding of the Business Architecture to analyze the feasibility of a variety of options.

Activity: Determining Project Scope

Scope definition should not be the first step in requirements development; it should be done during the project proposal process. How can the decision-maker(s) approve or disapprove a project without a clear understanding of its boundaries?

Activity: Preparing the Business Case

The business case is the logical argument for embarking on a project. It consists of contrasting the status quo (current situation) with the various options for addressing the problem or opportunity at hand and recommending the most appropriate option. In most cases, these options are being contrasted in terms of money (e.g., “If we spend $x on this project, it will result in $y increased revenue per year”).

Activity: Conducting the Initial Risk Assessment

An important piece of information that the decision-makers need is an understanding of the risks involved in a project. Clearly, you cannot do a complete risk-planning workshop before the project has been initiated (that is part of the Project Planning process). But an initial survey of the project risks can provide the decision-makers with key information.

Activity: Preparing the Decision Package

The BA has no authority to approve or disapprove any project. The people who do have that authority rarely have the time that is necessary to do the requisite research. So, the BA’s role in the decision-making process is to do all of the necessary research, and compile it into a form the decision-makers can use.

Activity: Selecting and Prioritizing Projects

After a project has been approved, it should not be a foregone conclusion that it will begin immediately. Projects must be prioritized against each other so the organization’s resources can be deployed in the most appropriate way. Again, the BA is not the decision-maker, but provides the necessary analysis to the decision-makers.

Project Work beyond Requirements

The last three activities that the BABOK includes under the “Enterprise Analysis” knowledge area are project-related activities that go beyond Requirements Analysis. They continue the theme of Enterprise Analysis by maintaining a broad organizational view of the project.

Activity: Launching New Projects

Here, the BA works with the appropriate people in the organization to ensure that the necessary resources, including the right project manager, are committed to the project. The BA’s unique role in these activities is to focus on the bigger picture of why the project was approved and how it fits into the bigger organizational context. This ensures that the intent of the decision-makers is honored as the project is framed and kicked off.

Activity: Managing Projects for Value

In this activity, the BA works closely with the project manager to ensure the project is tracking toward providing the value that was promised in the business case (above). The BA helps the project manager keep the project’s value proposition on track. And if the assumptions on which the project was approved turn out to be false, the BA can help the decision-makers determine their best response.

Activity: Tracking Project Benefits

In this last activity, the BA closes the loop on the business case (above). The business case proposed making certain investments in order to accrue certain benefits. After the project is over, the actual investments are known, and the actual benefits can be measured. At some appropriate time after deployment, the BA should report back to the decision-makers about how the results of the project compare with the business case. This discussion process will help the organization make better decisions in the future.

Expanding Your Value as a BA

Requirements Analysis is an important way for the BA to provide value to his or her organization. By adding Enterprise Analysis, the BA can dramatically increase his or her value by ensuring that every project fits well into the bigger picture and provides the best possible result to the organization.

Don’t forget to leave your comments below

Alan S. Koch, PMP is a speaker and writer on effective Project Management Methods. He is a certified Project Management Professional and President of ASK Process, Inc, a training and consulting company that helps companies to improve the return on their software investment by focusing on the quality of both their software products and the processes they use to develop them.

Mr. Koch’s 29 years in software development include:14 years designing, developing and maintaining software; five plus years in Quality Assurance (including establishing and managing a QA department); eight years in Software Process Improvement and 10 years in management

Mr. Koch was with the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) for 13 years where he became familiar with the Capability Maturity Model (CMM), earned the authorization to teach the Personal Software Process (PSP) and worked with Watts Humphrey in pilot testing the Team Software Process (TSP).

For more information about Mr. Koch: http://www.ASKProcess.com/experience.html.

This article was originally published in Global Knowledge’s Business Brief newsletter. (www.globalknowledge.com)

Copyright © Global Knowledge Training LLC. All rights reserved

Bad Ass BA; Peer Review. Part 1.

Written by Cecilie Hoffman on . Posted in Articles. 1 Comment on Bad Ass BA; Peer Review. Part 1.

Co-authored by Rebecca Burgess

badassreq1

Rubber Stamp or an Objective Quality Check?

When I ask for a “peer review” of a requirements document, I’m expecting a quality assurance check before the requirements document is presented to the Stakeholders. Some people think, “Oh, you’re my friend. I could never criticize your work.” But if you just rubber stamp (approve without a critical review) my work, you aren’t really my friend at all. If my friend/peer/co-worker/fellow BA doesn’t “take out a red pen” (or turn on track changes) and come back with lots of comments and questions, I worry. You would tell your friend that she had spinach on her teeth before letting her go back to the office after lunch, wouldn’t you? By the same reasoning, wouldn’t you do a careful review of her requirements document before it goes to the customer for review and approval?

There are a number of levels at which a document should be reviewed. In general, they are:

  • Business Case Synchronicity Check
  • Requirements Document Sanity Check
  • Requirements Statements Content Check
  • Requirements Document Housekeeping Check

These checks are filters; that is, if the document doesn’t pass the Business Case Synchronicity Check, you will stop the review. Only if the document and the business case are in sync, will you check for sanity, then if both of those checks pass, review the content quality of the requirements statements. Finally, do a housekeeping check on the version of the document that is ready to go to the Customer.

By checking the requirements document at each of these levels, you will be doing your peer a favor, and help her/him produce the highest quality document possible. We will detail the purpose and method for each check in articles over the next three months.

Why Peer Review?

Why bother with peer reviews in the first place? Here are a few concise reasons to use this powerful tool:

Improve the quality of the document being reviewed – More eyes are better.

Identify and correct project problems, errors, and omissions as early in the project cycle as possible – Early fixes are cheaper, by orders of magnitude.

Learn from colleagues’ insights and errors – If they can’t be a good example, they can be a horrible warning.

Broaden your knowledge of other areas of the business – The more you know about the business, the easier it is to move up to that “enterprise analyst” position.

Ask the stupid questions – see Bad-Ass BA Lessons. Part 2.

What excuses do people use to avoid peer review and how can you counter those excuses? There are many excuses, but these are the most common:

It’s scary! They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.

It takes time! Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.

We are already behind schedule! Would you rather let the customer catch the errors? Or worse yet, miss the errors?

I don’t know anything about that project! So you’ll limit your review to the more general, BA-level comments; that’s still valuable. Also see “Broaden your knowledge” in the reasons to do peer reviews, above.

It’s hard to do! True. And these articles will make it easier, so read on….

Business Case Synchronicity Check

The requirements document needs to sync up with the business case. Really, it does. We need to check benefits, ROI claims, reporting on ROI, success criteria, and the means to validate success.

Incidentally, for this article, the business case is assumed to contain a statement of the problem that needs to be solved, who the problem impacts, and the benefits, goals, and success criteria expected to be achieved, both financial and non-financial. For more information about business cases, see Building the Business Case and/or the Enterprise Analysis section of the BA BOK.

Check the box next to the item if you can answer ‘yes’ for the document you are reviewing.

 Part 1. Business Case Synchronicity
  • Is the business case document referenced in the requirements document?
  • Can you access the business case document from the reference (or could the business case be a figment of someone’s imagination)?
  • Is a stakeholder list available?
  • Do the individuals listed in the approvals section of the requirements document cover all the stakeholders?
  • Are the project benefits also benefits to the business? If the business sees no benefit, why is the project being undertaken?
  • Are the goals and/or success criteria from the business case represented by requirements (and can the requirements be traced back to the business case information)?
  • For each benefit/goal/success criteria, has a method for measuring the achievement of that benefit been described in the associated requirement, and does that measurement method make sense?
  • Are there clear requirements to provide any new data needed to measure the success of this project?
  • If the metric for the benefit/goal/success criteria is already implemented, has that benefit been baselined (measured in the recent past) and is the baseline data referenced in the appropriate requirement(s)?
  • Is there a target value and/or range for the benefit metric?
  • Is there a description of how and when the users expect to demonstrate achievement of the financial benefits resulting from the solution (after delivery of the project)?
  • Are the ROI claims (expected return on investment over a period of time) supported by requirements that describe how the business will periodically report on their progress towards achieving the ROI?
  • Based on the business case, do you believe that all of the critical business needs are represented by the body of requirements?

If one or more of these items is not checked, there is some risk that the requirements document does not match the business case. Your peer review mission is to convey these errors and omissions in a constructive manner. If you are expected to return written feedback, take time to explain what is wrong or missing, and provide examples if possible. If you will be participating in a peer review meeting, make notes of what you want to say so that you don’t sound too negative.

Have you convinced yourself that the requirements document and business case are in sync? No? Then the review of the requirements document should stop right now. The business case needs to be updated and everybody needs to agree that the business case is still valid. Once the documents are in sync, you can proceed to the sanity check, which will be covered in Part 2.

This article is part 1 of a 4-part series. The four sections are:

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

User Stories – Large Misconceptions. Part 1.

Written by Robert Galen on . Posted in Articles.

One of the larger misconceptions associated with user stories is that they are static; defined once and then never touched again. Another misconception is that they stand-alone as a requirement artifact. Another is that only a customer surrogate or product owner can write them. And finally, many miss the power of the acceptance tests as a clarifying vehicle for the story.

Over my next two posts, I want to address each of these in turn. Not only should these approaches help your user story writing, but your general requirements definition clarity and understanding should improve as well. And these misconceptions also assist distributed, non-local teams in eliciting stories that are more meaningful where they struggle to maintain active face-to-face communication.

User Stories are Organic!

If you study Scrum and product backlogs at all, you’ll realize that the backlog list of user stories evolves quite dynamically over time. Usually stories are created in a Story Writing Workshop at the beginning of a project effort. In this case the stories are often ill-defined and quite large-epics or even larger.

Coming out of the workshop, there is a tremendous amount of work to do on refining the stories, but certainly not all at once. The metaphor to keep in the back of your mind is – Tip of the Iceberg! You only need to refine the stories that are 1-2-3 or so iterations (Sprints) away from actual execution.

As you move forward, delivering those pre-defined stories, you actively groom the stories moving up on the backlog-getting them prepared for execution. Typically teams groom their product backlogs weekly. The process serves to refine the clarity surrounding each story. Often it will lead to other stories-breaking them into more meaningful units and discussing dependencies. Themes or packages of stories will emerge as well, as the product owner and team think about how best to couple stories into meaningful chunks for delivery.

The last and probably most important part of the dynamic is that the team factors in ongoing progress (execution velocity) and learning into their grooming.

While working with remote or distributed agile teams, it’s important to participate in these grooming sessions as a team. In this way, everyone is involved in the real-time conversations that are naturally part of backlog evolution.

User Stories are not a Catch-All Artifact!

The key driver for the content of requirements within agile team is the team itself. Let’s say a team member encounters a user story in a backlog grooming session that is simply too ill-defined to understand or estimate. However, they do understand the story well enough to suggest that-if they had a use case with it, one that was designed like one they’ve used/encountered before, they would have sufficient clarity to proceed.

In this case, they’re suggesting supplementing the Story with a known additional artifact form.

This is great!

Instead of trying to embellish the story as-is, simply link it to the newly created use case. In fact, it’s perfectly acceptable to link stories to all sorts of well known or used artifacts in your organization – traditional requirement (SRS) specifications, forms or templates, traditional use cases, agile use cases, wireframes, etc. All can effectively come into play to enhance and supplement your understanding of individual stories.

The caveat is that you don’t want to do this for every story. Let the individual cases or needs emerge from the team! Don’t create them too far in advance and certainly don’t create all user stories with the same level of detail. These extensions must come as requests from the team, i.e., they’re pulled as needed-preferably right before the implementation in the next iteration (sprint). Thus maintaining the just-enough and just-in-time nature of your story evolution.

One of the benefits of this approach is within distributed teams. These situations typically need richer documentation density with their requirements and this approach certainly provides it, while still maintaining an agile requirements approach.

As a final note, Alistair Cockburn has spent some time establishing the notion of Agile Use Cases. More information can be gleaned here on that topic – http://alistair.cockburn.us/Agile+Use+Cases

Next post, well finish with the other two misconceptions

Don’t forget to leave your comments below

Robert Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].