Jonathan Babcock has written an interesting article about the factors behind selecting Agile or Classic PM/BA methodologies.   His article includes a chart which compares the two methodologies in a two-by-two matrix which looks at the type of organization contrasted against the top of projects and which methodology makes the most sense.

An excerpt from the conclusion:

 Obviously, there are holes to be poked in any simplified method of making complex decisions, and Chin acknowledges that, “[d]eciding to employ agile PM is not a simple, black-and-white question.”

For all its simplicity, I did find the agile/classic matrix to make quite a bit of sense. At the very least, the approach Chin used provides some useful insights that can help in deciding which management method best suits your situation.

If you get the chance, pick up the book. Chin provides much more detail on the topic in his book than I have in this simple summary. He includes several other factors that may influence the classic/agile question, and tackles numerous other agile project management topics.

So, what are your thoughts? Would you agree on the factors used? How would your decision matrix differ from Chin’s? As always, I’ll look forward to your input.

Read the article here:

Blueprint’s own VP of Products, Tony Higgins, has written a piece for SearchSoftwareQuality about how to maintain and enhance legacy applications, effectively by reverse-engineering their requirements:

The skills of a forensic detective are required to gain an understanding of a legacy application’s implementation and its purpose. This understanding is essential to reducing risk and to making development feasible. Understanding is achieved by identifying the possible sources of information, prioritizing them, filtering the relevant from the irrelevant, and piecing together a jigsaw puzzle that elucidates the evolution of the application that has grown and changed over time. This understanding then provides the basis for moving forward with the needed development and hopefully turning the corner, providing a foundation for subsequent development.

Learn how to be a detective, here.

In this week’s episode we sit down with Theresa Lanowitz from Voke, Inc. and discuss some of the surprising results emerging from the Business Analysis market study currently being conducted. We discuss the “why” and “how” of the study and then turn our attention to what the study is telling us. We dig into how the application lifecycle is transforming, how the Business Analyst role is changing, and what needs to take place in the tools market to support Business Analysis going forward.

Join us for this quick preview into the study and stay on top of what’s happening in your industry.

Download the podcast, or grab it in iTunes.

Welcome back to Requirements Unplugged with Season 2, Episode 1 of the podcast!

After taking a short break we’re ready to kick off season 2 with our first ever “on the road” recording. We decided to take our Snowball microphone to Vegas and capture live interviews from the exhibit room floor of HP Software Universe. This was a great opportunity for us to meet some of our listeners and conduct interviews with BAs, Quality Associates, and even a developer. We simply asked: “What does the requirements lifecycle look like in your organization, and what challenges are you facing with regards to it?” My thanks to those who stopped by and joined us for an interview.

Although we still intend to spend time with some of our industry experts, in Season 2 we will also be focused on conducting interviews with BAs in the field so we can get even more real-world insight into what’s happening in the Business Analysis field worldwide. If you would like to be on the show and share your own insights into the requirements lifecycle in your organization please send me an email (keith.barrett@requirments.net) and I’ll be in touch.

In our next episode we’ll be chatting with Theresa Lanowitz from Voke regarding the BA Market Study and some of its surprising findings. There’s still time to participate in the study by clicking on the “Survey” link in the top right hand corner of the Requirements.net homepage.

Click here to download the podcast, or download in iTunes.

Got questions about the BABOK™? We’ve got answers.

The BABOK, produced by the IIBA™, is quickly becoming the source of consolidated BA practices (Tasks/Techniques) in the industry. Although not really a “how to” guide for each of the techniques, of even more value, it helps connect the Task-to-Technique relationships which brings clarity to how we chart our course through the BA process.

In this episode of the podcast we talk with Kevin Brennan, Vice President, BABOK, to gain a better understanding of how the BABOK came to be, who is working on it, what its primary purpose is, and what’s changing from Version 1.6 to 2.0.

We also discuss how Version 2.0 impacts the CBAP exam and what/when we might expect in Version 3.0. If we don’t cover all your questions regarding the BABOK, just send us an email and we’ll address it in a future episode or directly with Kevin via email.

Click here to download the Episode (iTunes/Quicktime required), or click here to subscribe to the podcast in iTunes.

Voke Inc., one of the most respected analyst firms on the planet, is teaming with the Requirements.net team in putting together the first-ever BA market sizing survey. This is an incredible opportunity to participate in assisting in one of the industry’s first market-sizing reports focused on the emerging business analyst space.

As we discuss on this site and in the Requirements.net Podcast “Requirements Unplugged”, the traditional definition of business analyst is under transformation. Business Analysts are now considered an essential control point in the quality lifecycle, with requirements definition and management being a central part of their job description.

We invite you to be heard. Please take 5 minutes to complete this survey. Click here!

A popular and valuable technique within Agile development teams is to create a “story card“, to capture requirements. Although initially created for iteration and release planning purposes, you can sometimes get away with using the story card as the requirement spec, as it may provide “just enough” details.

These story cards, which are typically captured on one piece of paper (a small one at that) and stuck on a wall (the planning board) with many other story cards, tend to provide a text-based description of who wants to do what and why, along with perhaps a GUI mockup and some test scenarios. This technique works well for very small requirements, but it may not scale well for larger or more complex requirements and software projects, in my experience.

I recently posted a small article discussing some of the approaches to consider when defining requirements within Agile teams over on SearchSoftwareQuality.com that you may find of interest. Read it here.

First, let me apologize for the delay between Episodes 8 and 9. Our goal was to provide a new episode each week., but the simple truth is, our schedules are hectic and the last couple of weeks have been especially busy. I’ve been wrapped up in a customer engagement, and Matt has been consumed by strong business demands with Blueprint. However, we were finally able to get to part 2 of our interview with Ellen Gottesdiener. (If you missed the first, you can download Episode 8 here.)

Also, we intend to record one more episode and then take a brief 2-3 week break before we come back with a new set of episodes for another 8-10 weeks. I would love to hear from anyone in our listening audience regarding specific topics or people you would like to see on our show. You can email me directly at: keith.barrett@requirements.net.

In Episode 9, we finish our conversation regarding requirements collaboration and turn our attention to Ellen’s second book, The Software Requirements Memory Jogger. We’ll also discuss her involvement in the IIBA™ and her perspectives on what the IIBA is doing for the Business Analysis community.

Lastly, I’ll give you a quick preview of Episode 10, in which we’ll speak with Kevin Brennan, Vice President, Body of Knowledge at the IIBA. Topics of discussion will be the Version 2 Public Draft of the BABOK™, how it has changed from Version 1.6, and what we can expect to see in the final release.

Thanks for helping make Requirements Unplugged one of the top listened to podcasts in the technology category today. We’d appreciate it if you could please rate our show, and/or leave comments in iTunes to show your support!

Download Episode 9 here, or grab it in iTunes.

Many software development teams today are faced with developing twice as much in half the time for even less budget. The risks this imposes to the business expecting and needing the software is much too high. A mechanism to deal with the risk is to rank and then prioritize requirements. Ranking requirements puts them in order of preference. Prioritization puts requirements in sequence of implementation after many considerations such as need, technical implementation, overall business strategy, etc. Some equate ranking and prioritization but they are different.

Continue reading…

Risk-based quality management is a new approach to risk mitigation in the end-to-end quality effort which has a critical linkage to requirements and requirements traceability.

In developing requirements, you have to consider both the business and the IT risk of implementing new capabilities. The notion of being able to capture both dimensions of risk, by requirement, provides a powerful way to evaluate the criticality of the functionality to the business. If you look at each requirement individually and assess the type of process it represents (e.g. new functionality), the frequency of use, the number of users affected by the features, the impact to the business if that requirement fails, and the probability of failure, you can arrive at an objective assessment of the priority/risk associated with that requirement.

Continue reading…