Requirements


Sometimes art is a metaphor and sometimes it is something else.

 

Clean Language’s pedigree is from psychotherapy and has found a home in coaching. It is also a valuable tool for discovering information about work products. As product managers, product owners, and stakeholders interact with the world and then describe a set of wants and needs they use metaphors. Metaphors are communication shortcuts that need to be explored. For example, product visions are often metaphor magnets. Most vision statements are considered internal and proprietary, therefore, they are hard to find (NDAs keep me from sharing the ones from companies I work with). Apple’s vision statement, according to Mission Statement Academy, is “We believe that we are on the face of the earth to make great products and that’s not changing.” If that statement was an input for building a product backlog there are several metaphors that would need to be explored so they can be converted into features and user stories. Clean Language is a way to get people to realize and describe what they know, what they think, how they feel while reducing bias in the results. Using clean language to identify and record requirements and needs follows the standard format for asking clean language questions with a few twists. (more…)

Large switch

Requirements are more than just on or off!

The Kano Model is a tool to help categorize product requirements.  The model created by Professor Kano groups all requirements into five categories:

  1. Must-be Quality, also known as basic needs,
  2. One-dimensional Quality, also known as performance attributes,
  3. Attractive Quality, also known as delighters,
  4. Indifferent Quality (neither improve or detract from satisfaction), and
  5. Reverse Quality (reduce satisfaction when achieved).

Most typical implementations of the Kano model tend to focus on the first three areas.   (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his  “The Alpha-Omega of Product Development” column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast.  In this visit, Gene discusses his recent blog entry titled, “Organizations as Systems – “Uneasy Lies the Head that Wears the Crown”.  Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute. (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

Special Note – SPAMCAST 409 was due to be posted last week, but bad things happened to my main computer and my backup decided to air-gap itself from the Internet.  That said, #409 is going up a week later so the Re-read Saturday news is a week out of date.  This week we talk about Chapters 22 and 23. I have declared that last weekend was a very stressful vacation from posting.  Now the show goes on!

In Software Process and Measurement Cast 409, we feature our essay on advice I recently provided to a listener to the podcast on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

Our second column this week features a visit to Jeremy Berriault’s QA Corner.  Jeremy and I discussed how QA should communicate with other leaders in the organization.  In the third and final column, Jon M. Quigley begins a three-part arc on requirements in “The Alpha-Omega of Product Development.” This week on discusses the elicitation of requirements.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 20 and 21.  Chapter 20 is a discussion of applying XP.  The short version is that there is no one perfect way to apply XP, which dovetails nicely with Chapter 21 which addresses the concept of purity and certification.  IF there is no one perfect way to apply XP, how can there be an absolute litmus test for XP purity?   

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next we are going to read The Five Dysfunctions of a Team.  This will be a new book for me, therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.

Next SPaMCAST

In the next Software Process and Measurement Cast, we will feature our interview of Jessica Long.  Jessica and I discussed storytelling.  Storytelling is useful in all types of organizations for both projects and as a tool in organizational transformations.  

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!  

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Stories help you visualize your goals

Stories help you visualize your goals

In the Harvard Business Review article, The Irresistible Power of Storytelling as a Strategic Business Tool by Harrison Monarth (March 11, 2014), Keith Quesenberry notes:

People are attracted to stories because we’re social creatures and we relate to other people.

The power of storytelling is that it helps us understand each other and develop empathy. Storytelling is a tool that is useful for presentations, but also to help people frame their thoughts and for gathering information. A story provides both a deeper and more nuanced connection with information than most lists of PowerPoint bullets or even structured requirements documents. Here are just a few scenarios (other than presentations) where stories can be useful: (more…)

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 342 features our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver: Agile Product Planning and Analysis, requirements and Agile.  Ellen and Mary provided penetrating insight into how to work with requirements in an Agile environment, from discovery to delivery and beyond.

This is the second time Ellen, Mary and I talked Agile requirements.  After listening to this interview turn back the hands of time and listen to SPaMCAST 200.

Ellen Gottesdiener is an internationally recognized leader in the convergence of agile + requirements + product management + project management. She is founder and principal of EBG Consulting, which helps organizations adapt how they collaborate to improve business outcomes.

Ellen’s passion is helping people use modern product requirements practices to build valued products and great teams. She provides coaching, training, and facilitates discovery and planning workshops across diverse industries. Ellen is a world-renowned writer, speaker, and presenter. Her most recent book, co-authored with Mary Gorman, is Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Here’s where you digitally connect with Ellen: Blog | Twitter | Newsletter | LinkedIn

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams, facilitates discovery workshops, and trains stakeholders in collaborative practices essential for defining high-value products. She speaks and writes for the agile, business analysis, and project management communities. Mary is co-author with Ellen Gottesdiener of Discover to Deliver: Agile Product Planning and Analysis.   

A Certified Business Analysis Professional, Mary helped develop the IIBA®’s A Guide to the Business Analysis Body of Knowledge® and certification exam. She also served on the task force that created the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline. You can reach Mary via: Twitter | LinkedIn

Call to action!

Reviews of the podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next up on Re-Read Saturday: The Mythical Man-Month

Get a copy now and start reading!

Upcoming Events

2015 PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presnetaiton is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September, BIFPUG in November. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on Commitment, Part 2. Is commitment anti-Agile?  We think not!  Commitment is a core behavior for effective Agile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Time for new shoes?

Time for new shoes?

I recently picked up a guide to a large conference that included a set of personas to help attendees decide which tracks would be of interest to them. The goal for the conference organizers was never the set of personas, but the guidance they provided to the attendees. The path from persona to the end goal in software development and maintenance often runs from persona to scenario then to user story.   Once a set of personas are established, the next step in the flow is to generate a set of scenarios. A scenario is a narrative that delineates purpose-driven interactions between a persona(s) and the product or system. Most projects require multiple scenarios to describe functionality that needs to be delivered.  An example of a very simple scenario follows:

As Tim Trackman completed his daily 10k, he found that the eyelet on his favorite running shoes had broken. He decided to order a new pair of the same shoes  so that he could continue training for his next half-marathon on his phone while he drank a cup of coffee in the hotel lobby.

The scenario includes a persona, rationale for the goal-driven behavior and the context in which the behavior will be accomplished. Unpacking the example:
Persona:  Tim Trackman
Goal-driven behavior: “order a new pair of the same shoes  so that he could continue training for his next half-marathon”
Context: “on his phone while he drank a cup of coffee in the hotel lobby”

Several other scenarios could be driven out of the same basic context, for example would Tim’s behavior be different if his favorite shoe style was not available? As with personas, a simple process flow provides a disciplined approach to generating scenarios.

  1. Familiarize the team with the goal of the product or system and the previously defined personas. This step sets the context for developing the persona. Typically the context is delivered by the product owner or someone from product management.
  2. Develop scenarios of the personas using the product or system. The scenarios are stories that explain how the persona interacts with system, their motivation and the how the interaction affects them.  I typically recommend using small sub-teams such as the Three Amigos to initially generate scenarios. In larger projects that will have multiple teams, I break the group into subgroups. The facilitator should use the context from step one to get the team to generate scenarios that fit the context.

    Remember when to write each scenario from the point of view of a specific persona. Stay away from glittering generalities. For example, if a story is written in which a persona sometimes does action, press the team to define the reason. The team must explore the motivation of the persona that would make them perform the action. For example in our running shoe scenario, if the scenario includes “sometimes Mr. Trackman searches for a shoe” the facilitator would need to push to get the team to define what the motivation for the behavior might be. These will generally require either additional scenarios or user stories later in the process.

  3. Consolidate duplicate scenarios. Carefully consider nuances in behavior before declaring two scenarios as duplicates. Nuances can be variants in behaviors can require nuances in code.
  4. Build a scenario map. Lay the scenarios out as an activity flow. Actions should flow from left to right. In our shoe scenario, Tim would buy shoes and then later get the shoes and perhaps even later return the shoes. Scenarios that involve the primary persona should be on the top row of the map (this can be used to define the minimum viable product) and tertiary personas at the bottom.
  5. Review the scenarios. Review the scenarios with the team(s). Use the review process to validate the scenarios and fill in gaps. The review process will generate conversation that can be used to add details to the scenarios. In larger projects the review process can be done as a single group (difficult to arrange) or through a number of reviews with smaller teams. The later will require a step to integrate all of the comments and feedback into the scenarios.

Coming back to our Logo Pint Glass example, a typical scenario for the “Brewdog would be:

When visiting a microbrewery, Tom “Brewdog” Pinternick, notices that there are logo pint glasses on sale. The brewpub has several varieties. Tom can’t remember if he has collected all of the different glasses being offered. Recognizing a potential buying opportunity, Tom opens the Logo Pint Glass app and browses the glasses he has already collected for this brewpub and discovers one the glasses is new.

In part 3 we will generate a set of user stories from our scenarios.

Next Page »