Over the past few years, I’ve spoken to user groups to share my experiences working with use cases, scenarios, and user acceptance tests in support of data warehousing and Business Intelligence (BI) BI analysis. Afterwards, many people ask me to summarize my recommendations. In response, I wrote a short article – Requirements Tips for Data Centric Projects. You can access it here (note: you may have to register).

In my article, I focus on analyzing the context of usage. In addition, remember this: to elicit, analyze, and specify requirements in this space, almost all of the time-tested data-centric techniques are still necessary.

People often asked me for additional tips and advice. What additional considerations for business analysis for BI?

Considerations for Business analysis for Business intelligence

Of all of those time-tested data-centric techniques, here are the ones I think are most important for this work:

1. You often need to perform data modeling (Entity-Relationship, Star Schema or both). To do this, be sure you have a sound grounding in these techniques.

2.  Your project may entail moving data to a warehouse or other data target. If so, you need to identify data sources and targets. Map your data sources to targets. Remember to conduct data sampling and use the samples to assess the quality or “cleanliness” of your data sources. Your analysis will likely include data cleansing, which requires a lot of detective work to hunt down the source of truth and structural business rules so your target data is correct.

3.  When your data will be delivered end users, be sure to analyze report content (e.g. select, sort, subtotal) and report presentation (i.e., how info will appear on a report or UI).

4. Specify quantitative information about your data. Specifically: volumes, percent growth, and which data records are likely to be accessed concurrently.

What about the International Institute of Business Analysis (IIBA) BABOK®?

The BABOK provides high level guidance on analysis for data warehousing. The BABOK includes the data techniques of Data Dictionary, Glossary, and Data Modeling.  Data mapping is mentioned as part of defining transition requirements.

Find in-depth information on analysis techniques for Data Warehousing in the DAMA (Data Management Association) Data Management Body of Knowledge (DAMA DMBOK)

I also recommend writings by Bill Inmon, Claudia Imhoff, Shaku Atre, Ralph Kimball and, for an Agile Perspective, Ken Collier’s recent book on Agile Analytics.

References:

• Brennan, Kevin. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide), International Institute of Business Analysis, 2009.
• Collier, Ken. Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing (Agile Software Development Series), Addison-Wesley Professional, 2011.
• DAMA International. The DAMA Guide to the Data Management Body of Knowledge (DAMA-DMBOK), Technics Publications, LLC, 2010.

Jennifer begins her article with the following: “With the proliferation of online articles and ebooks, old-fashioned paper books seem not to have a place in today’s world. Many experts, however, still find useful things in paperbacks and hardcovers. From technology to people and team management, these books still help developers out today. Here are what the experts recommend.”

Following are my recommendations – along with a few that didn’t make the article.

Category: Management and Career Development Books

Becoming a Technical Leader: An Organic Problem-Solving Approach

By Gerald M. Weinberg

This book was first published in 1986 and it’s still relevant today. Weinberg was the first person to write about the human side of software engineering, and I think of him as the Yoda of software development. His advice on leading software projects boils down to this: stay out of your own way, and know yourself.
— Ellen Gottesdiener, founder of agile consultancy EBG Consulting

Category: Software Methodology Books

Leading Lean Software Development: Results Are not the Point

By Mary Poppendieck and Tom Poppendieck

Leading Lean Software Development addresses one of the key issues that software development teams following the Scrum methodology tend to struggle with: how to focus on the larger organization, not just the team itself.

The Art of Agile Development

By James Shore and Shane Warden

This hands-on book deals with project management issues and offers a wealth of practical advice, particularly around test-driven development.

The ones that didn’t make the SD Times list

Food Rules: An Eater’s Manual

By Michael Pollan

Why?  Because of its elegant simplicity. 64  Rules. One rule per page, with a simple image on the opposite page. Gorgeously concise. Like software should be.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity

By Alan Cooper

This seminal book by the father of personas reminds us to understand the product from the outside-in. Not that we should ignore the inside-out, but it starts with the customer.

References:

deJon Lent, Jennifer. “The Best Books for Software Developers”, SD Times, December 15, 2011.

Sue Burk distinguishes between security requirements and security controls, shares four categories of security requirements, provides suggestions for eliciting security requirements, and explains why making them testable is important in her expert response.

References:

* The Software Requirements Memory Jogger

The presentation, entitled, Power Up Your Agile Planning and Analysis: Deliver Value via Structured Conversations describes how product stakeholders partner to develop a shared understanding of the product needs. I discuss how the partners gain a focused yet holistic understanding of the highest-value requirements and plan the project so that the delivery team builds the right product, at the right time.

In the podcast, I discuss with Joe the metaphor that Mary Gorman and I have been using, “structured conversations.” Structured conversations are used to explore and evaluate product requirements and clearly identify what to build and when to build it. These conversations fuel daily work on agile/lean product teams, enable them to populate and groom their product backlog, and to quickly analyze requirements so requirements can be allocated them to delivery cycles. These practices are described in the book Mary and I are in the midst of writing.

I hope you find the podcast interesting!

Resources that extend the concepts and practices I presented at Agile NYC on 18 October 2011:    

• Podcast with Agile NYC founder Jochen (Joe) Krebs – recorded just before my presentation
• Agile Planning and Analysis – Synergizing to Deliver Value Better Software, May/June 2011 [note*]
• Slicing Requirements for Agile Success Better Software (feature), August 2010[note]
• It’s the Goal, Not the Role: The Value of Business Analysis in Scrum StickyMinds.com, June 2011
• Harvesting Stakeholder Perspectives to Organize Your Backlog StickyMinds.com, January 2011

[note*]

You’ll find the slicing narrative tracks to what I shared in my presentation. Since Mary Gorman and I wrote the article last year, we have adjusted our use of some terms.  You can equate:

Article term = Training term

Expand-Then-Contract = Explore and Evaluate

Element = Dimension

Object = Data Dimension

Business Rule = Control Dimension

*Joe Krebs books:

Agile Portfolio Management, Microsoft Press, 2008

IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP)

The ingredients are:

Ingredients about the People

• The Right People
• Wise Groups
• Trust

Ingredients about the Collaborative Process

• A Shared Purpose
• Shared Space
• Focus Questions
• Serious Play
• Process Variety
• Flexible Structure
• Frequent Debriefs
• Collaborative Closure

Ingredients about the Products

• Pre-Work
• Doneness Tests
• Using Both Sides of the Brain

As I listen to our discussion in this podcast about these ingredients, I am reminded that these ingredients are core to great teams (not just great workshops). Why? Because these ingredients engineer and sustain good collaboration.

Collaboration works. Good collaboration results in people who do quality work, delivered to agreed upon acceptance criteria. As I discuss in the podcast, trust saves time. Visualization enables shared understanding. Transparent decision rules and process are efficient. Teams that slow down to reflect on their products and processes improve, continually.

Requirements by Collaboration was published in 2002; the year after the Agile Manifesto was published. I had by then a few years working with agile teams (at the time, we referred to it more as iterative development). Back then and still today, one of my coaching responsibilities is to help agile teams collaborate effectively. Good facilitation practices are essential for agile (and really all!) teams. I draw on these ingredients constantly as a coach.

In the book, I wrote about “doneness tests.” This same expression (“done” or “doneness tests”) is now commonly discussed in the agile community. In the context of having people collaborating in a facilitated workshop, I wrote that you need to “establish a set of criteria…to judge whether each deliverables is complete, clear, and correct enough to be acceptable” (page 58).

This same ingredient is crucial to continual flow of business value on agile team. When we at EBG Consulting coach agile teams and are facilitating product backlog grooming or agile planning workshops, we facilitate processes so the team defines unambiguous acceptance criteria for each requirement (often in the form of user stories). We also use “doneness tests”—acceptance criteria—for Big-View, Pre-View, and Now-View plans. We teach these practices in our collaboration for agile teams training.

I hope you’ll find the podcast useful.

What ingredients for good collaboration would you add or amend to my list above?

Resources:

• Assets from Requirements by Collaboration
• Amplifying Collaboration with Guerilla Facilitation
• Three types of trust I mention in the podcast (contractual, communication, competency) originate with the Reinas. I highly recommend their book:
  Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization, Second edition by Dennis Reina and Michelle Reina

This year’s conference, held August 9-12 2011, was attended by 1,600+ people. It was jam-packed with morning-to-night activities. The conference also included events to reflect and celebrate on the 10th anniversary of the Agile Manifesto.

We at EBG Consulting were pleased to have been selected (from over 900 submissions) to present three sessions.

Here are some of highlights and trends:

• Agile Requirements/Agile Business Analysis Time has Come: There was much interest in this topic. The half day workshop Mary Gorman and I presented on slicing agile requirements entitled “The Product Partnership: Structured Conversations for Delivering Value” was well attended and highly evaluated. It was generally acknowledged that even when agile teams finely tune and execute core development practices, they often hit the proverbial wall – deciding precisely what to build (the hardest part of software development, to paraphrase Frederick Brooks). That’s exactly where agile business analysis can play a vital role!

• Value of the Tester Mindset: Growing practices in the testing community using examples and scenarios. This is tightly aligned with what we at EBG Consulting have been doing; in fact, I co-presented a workshop “Requirements Exploration with Tester Collaboration” with Janet Gregory, co-author of Agile Testing.

• Business Rules Rule: The testing community and business analysis community are starting to collaborate on specifying and validating business rules. Mary Gorman led an open space session at the pre-conference Agile Testing day on business rules, examples and tests and had a lot of agile testing thought leaders thinking in new ways about this! Mary also presented a conference session entitled “Business Rules Essentials for Quality Software.”

• Pull Production and Customer Support Forward: there is growing interest in the round-trip engineering by pulling production support forward by releasing the product frequently, putting the release into the hands of the customer. This is enabled when teams practice continuous integration—frequent integration of code verified with automated tests—and take it a step forward with continuous delivery.

• Numerous good sessions on large-scale/enterprise adaption (and organizational change management implications)

• Integrate Lean Startup Practices: Growing emphasis on integrating lean start-up ideas on agile projects, especially the need to identify you are solving a real problem for the right customers e.g. Customer Discovery) and then validate that you can sell your product to that target customer (e.g., Customer Validation). Throughout, you do this using very short delivery cycles).

• Kanban has Charisma: More and more teams are adapting kanban (flow vs time-boxed) agile practices, or combining scrum with kanban. (An aside: several of our new clients are using kanban.) These client experiences further testify to the value of EBG’s agile requirements slicing practices for ‘pull’ as well as time-boxed delivery models.

Resources:

• On continuous delivery:
• Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation by David Farley and Jez Humble
• Selected online readings on continuous delivery:
• Jez Humble’s blog
• Deployment pipeline (chapter from Continuous Delivery book)
• On lean start-ups:
• Four Steps to the Epiphany: Successful Strategies for Product that Win by Steven Gary Blank
• The Entrepreneur’s Guide to Customer Development by Brant Cooper and Patrick Vlaskovits
• Selected online readings on Customer Discovery and Validation:
• Steven Blank’s blog
• Eric Reis’ blog
• Ash Maurya’s blog
• Applying the lean startup model to the enterprise (Jez Humble slides)

Yamo’s interview got me thinking and reflecting on my own professional learning journey and dig into the two books I’ve written (so far ).

Writing a book is a daunting task. It is a learning journey in and of itself. When I began my first book, Requirements by Collaboration, I had no idea how much I’d learn from the writing process.

Listening to this portion of the author cast reminded me how grateful I am to all the mentors—accidental and intentional—I have learned from. And, those I continue to learn from.

One of my first mentors, Donna Dean, started a Quality Circle in our analyst/programmer group and entrusted me with a leadership role. That was 1981. It was my first exposure to lean, kaizen, and TPS. Donna was ahead of her time, in many ways. I am grateful to her.

How is your learning journey going? How do you learn and grow?

I believe that there is a lot of cross-fertilization benefit to be gained when people with skills in different disciplines collaborate closely toward shared ends. This is very true for the disciplines of testing and business analysis. The tester mind-set is crucial for verifying requirements. The business analysis mind-set is crucial for validating requirements.

By incorporating analysis practices into the testing discipline and testing practices into analysis, we collapse the traditional “V” model of verification and validation. This enables development teams to more efficiently and effectively identify the right requirements, and get the requirements right.

Agile practices, when done well, focus on delivering value and provide the freedom for the team to collaborate toward that shared end. As Mary Gorman and I have been saying, “it’s the goal, not the role.” By that, we mean that teams need to focus on delivering value each and every day, and not on who does what.

I hope you can join us for one of these events.

Resources:

• Acceptance Testing: Elicit and Validate Requirements for Success
• “Slicing Requirements for Agile Success“
• “It’s the Role, Not the Goal: The Value of Business Analysis in Scrum“
• Specification by Example

Sue Burk shares the value of scenarios to define acceptance tests, and other practical techniques to improve your success with these data-centric projects in her expert response.

Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair, I wanted to put together a team of people who represent a cross-section of business analysis and requirements skills. I also wanted our presenter/facilitator team to be composed of folks with solid knowledge of traditional as well as agile practices. We have that with our team: Joy Beatty, Kent McDonald, Ken Pugh, Linda Rising, Doug Talbott, and me.

Business analysis—and the good requirements that result—is increasingly important for both strategic planning and tactical product delivery. Business analysts require multiple skills: strategic thinking, requirements modeling, requirements elicitation and communication, business architecture and user experience, and customer relationship management. And, they need to be able to adapt analysis practices for traditional and agile projects.

Because the two-day workshop agenda incorporates sessions focused on these skill areas, I chose the metaphor of a playbook, like the ones football teams use: in addition to skills and knowledge, analysts need a diverse toolkit of methods and practices.

Here’s how it works. We start and end each day as a community to prepare and retrospect, continually focusing on our playbook. In-between, we are holding parallel tracks so attendees can focus on practices they need or want to improve in their playbook. Our sessions include opportunities for people to practice eliciting, analyzing, specifying, and validating requirements.

An aside: in the analysis and requirements realm we prefer to use the term “elicit” vs. “gather,” since requirements are not just sitting around waiting to be picked up.

Some sessions will cover higher-level topics such as strategic thinking. The idea is to learn how to focus on the right things in the first place, and on essential customer collaboration practices that work.

We are using the same case study throughout the sessions, so participants can practice skills across sessions within the same problem domain. However, the practices we are sharing are useful regardless of the specific domain you work on “back home.”

If you make this event, I hope to see you at another one, soon! Check out our Events calendar for upcoming conferences, webinars or local meeting we, I, or another EBG’er might see you.