Author Archives: IAG Consulting

SCRUM: Playing Planning Poker

In order for the Team to provide a Commitment they need some way of estimating the work effort of the Product Backlog Items. To help teams determine their commitment level Scrum employs a rather unique way of estimating through a technique known as ‘Planning Poker’. Basically it works like this:

1. Each Team member (except the Product Owner) is given a deck of Planning Poker cards (that carry a value of between 0 and 200).

2. The team reviews each product backlog item and decides which is the smallest / least complicated item and assigns it a value (e.g. 2-points). It really doesn’t matter what units you use (it could be popsicle sticks for all that matters) as the estimates are all relative to each other.

3. Then, starting from the top the Team selects the first item from the product backlog

Continue reading

Understanding Your Role in a Requirements Session

1. Requirements Team (Facilitator, BusinessAnalyst)
Enable the requirements discovery process by:

  • Asking relevant questions
  • Recording answers provided by SubjectMatter Experts
  • Keeping the process moving
  • Utilizing effective facilitation anddocumentation skills
  • Keeping the discussion focused onobjectives and scope
  • Confirming understanding among/withparticipants
2. Business Leader / Project Sponsor
Provide the business vision by:
  • Explaining the problem/opportunity
  • Defining the vision
  • Defining the business objectives
  • Determining the measures of success
  • Defining high level process andrequirements

5 Critical Points BAs Need to Remember

1. You will always be describing a process. Determine the process that is to be automated, and describe it.

2. You must understand something at one level before you can truly understand it at a lower level. Start your analysis by describing the overall process at ahigh level of abstraction to form the framework of the rest of your analysis.

3.  You must describe “What” not “How”. The business process should be described independent of how a system would help a user to complete the process.

Continue reading

Key Questions for Breaking Through on a Difficult User Story

The Challenge

User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface.  Some should be broken up in to multiple stories.  You may not know how best to write a user story and communicate needs.  Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.

Break Through Thinking

Make this break through:  it’s not the designs you bring, or the solutions you suggest, that will clarify needs – it’s the questions you ask that determine how quickly a solution can be implemented.  Good questions showcase your understanding and build trust between you and the user.  Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:

 

Determining the success criteria

Here is a simple approach to clarifying user stories: attach your clarifications as acceptance criteria or test conditions.  The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.”  By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.

Continue reading

Determine when you are “done”

Four simple tests to assess if requirements are not done

These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:


If the requirements lack context: Requirements always exist to support “what” the business wants to do, not “how” it wants to do it. The “what” part of this is the context of business process. Lack of understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the structure of the documentation.

If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called “dependencies”, check the “issues list”, and look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know part of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.

Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time-bounded (easy to remember as ‘SMART’). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.

  Continue reading

Maturity is More than Looking for Grey Hair and Wrinkles

The concept of capability maturity has been around since Deming first started the quality movement in the 1950s. So what’s a “mature” business analyst? Are we really looking for grey hair and wrinkles to determine that individuals or collective organizations are consistently going to perform at a high level of quality? Is there some measure of “prune-i-ness” that you can use to pick out top performers?

I think not.

Overall, if an organization wants to change the performance level of its business analysis function, it has to focus on six underlying capabilities: processes, practices, people, technology, organization and deliverables. Sure, you can get a short term bump in productivity by being draconian, but it is simply not possible to make material, sustained change without systematically addressing these six capability areas. The question in each of the six areas is not whether you have, for example, processes or not. The question is the degree to which an organization accepts and adopts that process as the best possible way of doing things. This means that some organizations think they have a process for requirements definition and management … but admit it’s actually quite ad hoc. At the other end of the spectrum, organizations have institutionalized the process, and can describe their efforts to continuously optimize this process so that it’s alignment to delivering stakeholder value is maximized. These two examples are the extremes of requirements definition and management maturity.

Continue reading

Outsourcing A Requirements Center of Excellence

 

There are four situations where companies should strongly consider and investigate outsourcing the Requirements Center of Excellence (RCoE):

 

1.       Growing very rapidly:  Where a company is growing very quickly, increases in productivity translate into direct cost savings.  Any improvement made in application time-to-market is critical to the organization.  High growth companies can leverage the outsourcer to bring mature processes that simply could not be contemplated given the stress on the internal organization for growth.

Continue reading

It Ain’t Easy Being Agile

You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.

 

itainteasy1

Continue reading

Requirements-Driven Waste in IT Spending

High requirements maturity translates directly to IT spending efficiency. These efficiency advantages become more pronounced as the size and complexity of projects grow. By investing in requirements maturity, organizations can not only improve business analysis capabilities, but also reduce IT spending waste. This means a greater level of certainty and higher success rates for all IT development projects.

Click here for more on Requirements and Business Analysis

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

What Is Requirements Discovery?

Requirements discovery is also often referred to as requirements elicitation, requirements gathering, requirements analysis, and requirements definition. We prefer to use the term because it’s a little less high-brow, more meaningful, and more appropriate to the activity it is intended to describe.

The Requirements Discovery Process

Requirements Process FlowThe typical process for requirements discovery involves the following six activities:

> Requirements Planning 
> Requirements Elicitation 
> Requirements Analysis & Documentation 
> Requirements Verification & Review 
> Requirements Validation & Acceptance 
> Requirements Change Management

Origin of the Term Requirements Discovery

Legal DiscoveryThe term was initial coined by Ross Little in the late 80’s. Ross, now a principal with IAG Consulting, adapted the term from the legal profession. As a practicing Business Analyst, Little was working to evolve methods, practices and standards from the worlds of structured systems analysis, software engineering, total quality management and business process reengineering. Little credits his father, a lawyer, introducing him to the legal discovery process – and the genesis of the idea to apply some of those concepts to how organizations should gather information to define requirements for business solutions and change.

In the legal community “discovery” is the approach used to determine the facts about a case. Legal discovery mechanisms may be traced back to procedures of the ecclesiastical courts in England as early as the 16th century in which litigants delivered pleadings and obtained answers by means of examination under oath. As legal discovery in American law is the pretrial phase of a lawsuit, requirements discovery is the pre-design phase of a business transformation, or application development project.