Project Management

Requirements Management Ruminations

by , , , , , , , , , , ,
A collaborative blog with contributions from members of the PMI Requirements Management Community of Practice and various authors and presenters who have dealt with the topic of requirements management.

About this Blog


View Posts By:

Cameron McGaughy
Abdulilah Angaa
Mike Frenette
Beth Ouellette
Victoria Cupet
Jhansi Vijayarajan
Bobbye Underwood
Sally Elatta
Richard Larson
Elizabeth Larson
Ellen Gottesdiener
Mary Gorman

Recent Posts

Natural Language Processing to sharpen up your requirements

Automating requirements review using Natural Language Processing

Actionable Agile Tools - a book review

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Project Managers Find New Rhythm at PMI® Global Congress’ First Agile Open Jam

Natural Language Processing to sharpen up your requirements

It's great to on the bleeding edge sometimes, isn't it? I was fortunate enough to be invited to meet with Jordan Kyriakidis, CEO of QRACorp in my home town of Halifax, Nova Scotia when he saw I was speaking at the annual Professional Development Symposium. Jordan introduced me to the concept of Natural Language Processing as it applies to requirements documents. Jordan and I (well, mostly Jordan) put on a webinar today to discuss this very topic. You can view it here on

Here's a handy shortcut:

But sometimes it is easier to read about things, so I thought I'd talk about it here at a high level, at least.  

Natural Language Processing is gaining a lot of attention these days. Automatically going through documents and looking for patterns or comparing to knowledge bases, or comparing one document to another to see if they relate one to the other are just a few things NLP can be used for. 

Imagine a world where a computer application reads a document instead of you and points out all the places where the requirements writer has been too vague, imprecise, or has not provided enough detail?  How about one that compares all the requirements documents in the organization and lets you know when it detects inconsistencies between your work and others?  Or maybe one that knows the jargon of the profession in which you work, and can point out misuse of terms?  Or one that is able to look through your requirements and tell you what is missing?

Seem like it might be a bit of a stretch?  Well, some of what was covered in today's webinar is not available ... yet.  But some of it is. And that's what bleeding edge is all about, isn't it?  Working with new concepts, innovating new methods and the tools to go with them, envisioning the future. 

Now you can decide for yourself whether the webinar might be worth a listen.  

Many thanks to Jordan Kyriakidis for sharing this advanced knowledge.



P.S. Below are some comments which I thought were quite generous and gratifying from the over 1,200 attendees: 

  • Thank you. This was enlightening
  • Amazing conference
  • Great presentation. Thank you
  • Thanks!! Great info!!
  • Interesting webinar, glad I didn't miss it. thank you
  • AWESOME!!!!
  • Thank you ... very good presentation.  Excellent on defining requirements!
  • Thank you, interesting and informative!
  • Thank you for a very fine presentation.
  • One of the BEST webinars
  • JORDAN - AWESOME cutting-edge at its best!! Keep going forward and sharing.
  • Thank you! Awesome!
  • Great presentation. Thanks
  • Michael, Jordan thank you for your presentation. It's very useful!
  • Great presentation and ideas
  • Thank you for a very interesting talk.
  • Thanks for presentation, great webinar.
  • Fantastic. thank you.
  • Thank you & was great presentation!!
  • Great presentation
  • Great presentation. Thanks a lot
Posted by Mike Frenette on: July 14, 2016 12:00 AM | Permalink | Comments (10)

Automating requirements review using Natural Language Processing

Ever wonder if the requirements you are writing make sense? Do you wonder about what you could do to improve them?  Make them more concise?  More accurate? 

I ran across a company recently that has developed a new approach to this with a product that scans the requirements you tag in your document and tells you what might be improved.  The product is quite new, and they are looking for beta testers if you are interested. You can sign up at  I already have and am looking forward to trying something that is leading edge.

Have you had experiences with similar tools? Or is this approach using natural language processing new to you?  Comments welcome!

Posted by Mike Frenette on: May 05, 2016 12:21 PM | Permalink | Comments (2)

Actionable Agile Tools - a book review

This Blog is about requirements management, so a book I read recently about Agile tools seemed to apply since some of them are about managing the Product Backlog. 

"Actionable Agile Tools" is the name of the book, and it was written by Jeff Campbell.  It is a short book - a compendium of tools he has developed over the last ten years as a Scrum Master and Agile Coach.  Jeff is Canadian, but has been living in Sweden for many years.  I met Jeff at an event called a "Scrum Beers", which is a gathering of people who use Agile.  They meet for presentations, followed by some informal networking and libations.  Scrum Beers is really about Agile, not just Scrum, and is now present in three countries. Check it out at

If you buy the book at, you can tweet about it at #actionableagiletools.

So - on with my review!

First of all, I must say that Jeff has given some innovative names to some of the tools he mentions. I hope you enjoy the names as much as much as I did.  The book is simply structured with a brief introduction and then a chapter on each of the tools.  I’ll comment on each of them, but of course you really won’t see the whole picture until you read the book.

  1. Experiment Driven Change – Fixing things found in retrospectives by experimenting with a change immediately, and tossing it out or keeping it when you discuss it again at the next Retrospective.  This tool is meant to stop the “never do anything but talk about it” syndrome.

  2. Door Calendar – An information radiator about events you can create with some simple sticky notes.  Put it on a door the team uses every day.

  3. Doing Dots – Put a dot on a post it note reminder to do something every day nothing changes. These notes might be on your Kanban chart or other card wall.  The more dots, the older the item. This stops things from not getting attention (lots of dots? Needs attention!), or becoming fixtures that everyone ignores.

  4. Bugs for Breakfast – Increase your quality focus by having a team breakfast on a regular (start with weekly) basis where the main discussion is about bugs and how/when to fix them. 

  5. Communication Protocol – Discuss with your team all the means of communication you have and the pros and cons of each. Gain team consensus on how, why and when each should be used.

  6. Tasty Timeboxes – Have food at Sprint Reviews, but make it different food for each Sprint.  This allows people to easily refer to past Sprints and also gets some team spirit going as you choose the food for the next Sprint. For fun, you can use the alphabet to choose the food. Remember the Chicken Curry Sprint and how Maggie said…

  7. Where Does the Time Go – Categorize time such that in the daily Scrum each team member reports on the category into which the time they are talking about falls.  Was it planned?  Critical? Support? Admin?  This highlights productive versus wasteful time.

  8. Event Log – Keep track of events during a Sprint on a large sheet (date/event) to be used at the Sprint Retrospective. Make updating it a daily ritual.

  9. Resilience Map – List the skills (rows) you need on your team, then map it in a large matrix you put on the wall showing the level of skill (columns) each team member (multiple per cell) has in each skill area. Keep it up to date as the team changes.  This lets you know who has what skills when people come and go or need help. It also acts as a tool to see where you have skill shortages on the project.

  10. Recruitment Retrospectives – Empower people joining the team to invite anyone they want to retrospective meetings to discover holes in the on-boarding process. Create specific experiments to plug those holes and follow up on them. Use the newest person in on-boarding the next new hire.

  11. Appreciation Flowers – Give a post it note with your team members name and flower drawn on it for them to take back to their desk.  Write on the back of the note why you are giving them a flower.  A great and no cost why for people to show appreciation.

  12. Value Poker – Like Planning Poker where the relative complexity of stories are set by the team, this allows stakeholders to rate the value of each story.  Helps you understand the business value of each item so you end up with a Prioritized Product Backlog.

  13. In-Line Definition of Done – Make a checklist of items that must be ticked off before something can be considered “done”.  Put it against the story, not in some place that won’t be noticed until someone says something is done.  Helps your team focus on what “done” means.

  14. Not Now Backlog – Choose a timeframe with your team and stakeholders beyond which you will not consider items for the backlog. Rather than throwing out the ideas, add them to the Not Now Backlog.

  15. Visualized Flow – Use a Kanban Board to show In-flows and Out-flows – that is, the movement of a story from its inception showing who came up with it, through refinement (by the Product Owner and by the Team) until ready, and finally done.  This allows anyone to see the status of work as it goes through each stage until it is finished.


Posted by Mike Frenette on: January 18, 2016 11:44 AM | Permalink | Comments (11)

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Categories: Business Analysis

This blog is in response to some great discussion and questions that arose during and after the webinar I gave on on March 4, 2015. Some of these topics included the role of the BA and PM, certifications, and Agile.

1.       Can the PM and the BA play both roles? There were many comments and questions about the role of the PM and BA, how they worked together, whether it was one or two roles. The industry has swung wildly between recognizing the BA and PM as separate roles and thinking it makes sense to combine them. I’ve written several Trends articles on this subject, starting in 2009. So where are we in 2015? I have not changed my opinion since 2009. The two roles require different skills and competencies. We tell our clients to think of the analogy of building a house when thinking about roles. The sponsor is the homeowner, the builder/general contractor is the PM, and the architect is the BA. Mike Frenette also used this analogy when he asked the question during the chat, “Would you use an architect to build your house?” Are there people who have the skills to do both? Yes, indeed. Does it make sense for those people to do both roles? Not on large projects it doesn’t. However, even though I’m not jumping up and down about it, I still stick by my prediction that in the near future, business analysis work will be performed by a variety of different roles-- PMs, developers, business stakeholders, etc.

2.       What is the relationship between the two roles—does one work for the other? The question came up about moving from a PM to a BA role and vice versa. We used to think of the BA role as working for the PM role. Now we’re seeing the roles more as peer-to-peer. And interestingly, I’ve seen quite a few PMs becoming BAs, as well as BAs who had been promoted to PM going back to the BA role.

3.       What about the BA on Agile projects? BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Regardless of who does it, business analysis is essential to Agile projects, which still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the features. This in-depth analysis is perfect for a business analyst. The BA can also coach the product owner and help ensure requirements are tested.

4.       PMI-PBA vs. CBAP. There was a great deal of discussion on the chat log about certifications—which is better the PBA or CBAP. Here’s a summary of some of the blogs and articles I’ve written on the topic:

a.       Whether it’s ideal or not, many people play that dual role of BA/PM.  If you do, the PMI-PBA is a perfect certification for you.

b.      The CBAP is a gold standard and will continue to be so in the area of business analysis. There are fewer than 5,000 CBAPS today—it’s a hard certification to obtain, but you might want to pursue it if you’re planning a career in business analysis.

c.       It makes sense to get both if you’re a consultant working or expecting to work in various organizations. Trainers, too, benefit from having both designations.

Additional questions:

·         What other projects, besides software development and process improvement works well with Agile? At Watermark we develop our courseware using Agile. We have also found that our marketing campaigns, and for that matter all things marketing, are best done with an Agile approach.

·         Is PMI's Business Analysis for Practitioners: A Practice Guide the same as the BABOK®? No, it’s not. However, all of us who were lead authors on the PBA Practice Guide were also lead authors on the BABOK® Guide. There are many similarities, but some very, very large differences. More on this subject for anyone interested.

·         Does anyone have suggestions for studying for the PMI-PBA exam. Absolutely! Among other things, my husband Richard and I will be giving another webinar on the PBA on April 17 at 11:00 CST. I’d be happy to provide more information –articles, blogs, and lots and lots of information--about the PBA and CBAP certifications, so please feel free to reach out to me.

For more information on articles, blogs, and free webinars, please visit


Posted by Elizabeth Larson on: March 13, 2015 01:25 PM | Permalink | Comments (16)

Project Managers Find New Rhythm at PMI® Global Congress’ First Agile Open Jam


Agile Open Jam PMIWhat happens with PMI conference attendees encounter a new way to interact about Agile? We found out when I hosted another first: an Agile Open Jam with global project managers. With the help of some excellent co-facilitators, I conducted an Agile Open Jam at the PMI® Global Congress 2014-North America, with the theme of Business Analysis and Product Management in Agile. (To learn about other firsts I’ve shared with the product management community, read my prior blog post.) This Agile Open Jam is noteworthy for both its format and content.

Noteworthy Format

PMI conferences follow a traditional format of sessions, each of which is comprised of presentations and keynotes. As many of you know, Agile conferences tend toward highly interactive and experimental sessions along with numerous networking and collaboration opportunities. Open Jams are highly collaborative, as explained in a prior blog. An Open Jam is an entirely different format for the more traditional format of the Global Congress.

Noteworthy Content

Content-wise, the conference included a small number of sessions on Agile. As you likely know, the global project management community continues to develop its interest in and transition to agile/lean project management. (PMI members can find our webinar on Value in PMI’s Agile Community of Practice archive.) At the same time, PMI has become attuned to business analysis and is offering a new certification in business analysis. (We at EBG have been providing expertise to PMI as it elevates business analysis within the PMI community.) Consequently, PMI added a new Business Analysis and Requirements track to the Global Congress. Dave Bieg, PMI’s Requirements Program Manager, asked me to help design the track. This gave me the opportunity to suggest we do an Agile Open Jam, and with Dave’s help, PMI agreed to this unique and innovative format—and content which effectively straddled both the Agile and business analysis tracks.

Summary Report

Our PMI Agile Open Jam attendees spanned a wide range of agile experience and brought a number of unique questions and puzzles. You can get a flavor of the topics and the collaborative atmosphere in our visual report.


Thanks to the Agile Alliance and PMI for sponsored the two-day Jam. And a special shout out to the team of experienced and energetic agile facilitators who engaged so effectively with the attendees:

Thank you, Jeff Adams, Sue Burk, Joseph Flahiff, Mary Gorman, Shane Hastie, Horia Slusanschi, Ram Srinivasan and Barry Young!

As it was the first Agile Open Jam at a PMI Global Congress I especially appreciated the attendees who jumped right in by offering topics and participating in discussions. Their willingness to try something new was inspiriting!

Posted by Ellen Gottesdiener on: January 11, 2015 08:19 PM | Permalink | Comments (7)

"The remarkable thing about television is that it permits several million people to laugh at the same joke and still feel lonely."

- T.S. Eliot