The Agilist Network

Tales and Tips from Agile Software Projects

Posts Tagged ‘non functional requirements’

Agile Trifecta

Posted by kenhoward on May 1, 2009

I was thrilled to get notified this week that all three of my talks were accepted for the Agile 2009 conference in Chicago on August 24-28.    Althoagile2009ugh I’ve spoken at many conferences in the past, this will be my first opportunity to speak at this popular conference.

I will be presenting:

  • It Takes Two to Tango; Four to Square Dance:   Colleague Barry Rogers and I are presenting a session on the often overlooked “Individuals and Interactions” element of the Agile Manifesto.   Learn how psychology, sociology, behavior, attitudes and other soft’ish elements can make or break a project.   We present tips on how to capitalize on and leverage the human side of projects.
  • Handling Non Functional Requirements on an Agile Project: For those of you who remember my post on building a better mousetrap (here)  you’ll recall the discussion about how to craft the best solution from the 4400 possibilities.    Non Functional requirements are often overlooked on Agile projects, yet they often determine true success or failure.   In this session I lay out strategies for handling non functional requirements without deviating from core Agile objectives.
  • The Covert Agilist: Not everyone is jumping up and down waving the Agile flag.  In this session I’ll describe one of my engagements where I was told “No Agile!” on day one.   I’ll show how, despite this mantra, our team successfully introduced and used Agile right in front of the watchful eyes of our client.   No, they didn’t complain.  Why?  How could they complain about progress and success!   Nevertheless, this story doesn’t have a happy ending.  Come to this session to find out what happened.

Registration for this popular conference is underway.   August will be here before you know it, so you may want to book your travel early.   The conference webpage is here.

I look forward to the opportunity to meet up with old clients and colleagues, and to meet some of you who have been kind enough to post comments and/or send emails about my blog.


Posted in Uncategorized | Tagged: , , , , , , | Leave a Comment »

Don't Overlook the Adjectives in User Stories

Posted by kenhoward on December 19, 2008

adjectives_largeTake a look at two versions of a User Story, which are written using Mike Cohn’s popular format:

Version 1

As a customer service rep, I can calculate a customer’s account balance so I can provide it when a customer calls to request it.

Version 2

As a customer service rep, I can easily calculate a customer’s account balance so I can promptly provide it when a customer calls to request it.

There are two words added in the second version of this User Story that could potentially derail the development effort if ignored.   It’s easy to overlook adjectives and adverbs as adornments that don’t add value.    While version 1 emphasizes a functional requirement of the system, those two little words added in version 2 specify two non-functional requirements that mustn’t be overlooked.

Out of the box, Scrum and other Agile methods may not sufficiently address the handling of non-functional requirements.    The method I have always used for removing ambiguity from non-functional requirements is based on Gerald Weinberg’s writings about system attributes.   This also aligns with popular practices of Thomas Gilb.

Adjective/Adverb Promptly
Target Account balance calculation process
Measured by Number of manual steps required
Minimum acceptable 1
Maximum acceptable 4
Measured by Time from submit until calculation appears
Minimum acceptable 0.5 second
Maximum acceptable 3.0 seconds

By now, the Scrummers out there may be squirming, but hear me out.   The exercise of negotiating metrics for non-functional requirements with the Product Owner will likely result in one of two outcomes:  1) They will (painfully) specify the values, or 2) They will cede that they don’t really feel that strongly about the attribute.

I’ve heard of some folks who write user stories written explicitly for a non-functional requirement itself.    This could feel like squeezing a square peg in a round hole.   A more pragmatic approach would be to simply create a task supporting the user story above to the effect of: “Specify measurement criteria for promptly” and “Specify measurement criteria for “easily”.    The deliverable for these tasks could potentially conform to the format I described above.

Posted in Uncategorized | Tagged: , , , , , | 2 Comments »

One person’s Walmart is another person’s Macy’s is another person’s Neiman Marcus…

Posted by kenhoward on December 18, 2008

walmartWhen kick-starting a new team, it’s helpful to be empathetic to each team member’s background and experience.   Interpretation of such concepts as productivity, efficiency, and quality can differ based on an individual’s background, values, and previous experiences.   Ambiguous goals can lead to ambiguous results.

A role of the Scrum Master is to facilitate the team toward common goals.  At face value, this sounds like a “motherhood and apple pie” statement.   Under the covers, this can be more challenging than it appears.    When goals are stated in subjective’ish language, each team member’s interpretation is likely to be different.

Tip: Know the Target of a Goal.

There’s a difference between goals for the project and goals for the thing being built.

Project goals tend to pertain to the schedule, resources, and work.     Project goals usually contain language related to efficiency, productivity, being on time, providing good customer service, meeting budgets, etc.

Product goals pertain to attributes of the system being developed.   Non-functional requirements fall into this category: The system shall fast, efficient, comprehensive, fault tolerant, user friendly, etc.

Tip: Make Adjectives Measurable.

Adjectives are inherently subjective.   Product goals such as “User Friendly” and “Fast” have a zillion interpretations.   Rather than “System shall be fast”, try a more specific goal such as “Each screen must display within 3 seconds of request”.

Similarly, a project goal such as “Work Productively” says nothing.   This is where Scrum tactics can help.  Establishing a specific goal for the team’s velocity is measurable, reportable, and actionable.   Once the team agrees to a goal for its Velocity, it can be tracked and reported as a shared measurable goal.

Tip: Radiate the Goals that Matter.

When goals are written in a document and filed away, they can be forgotten.   If a goal is really important, consider radiating it – perhaps post it on a wall in the team room.   If a goal is not worthy of being posted, perhaps it’s not really that important.

Posted in Uncategorized | Tagged: , , , , , , , , | 2 Comments »