Tag Archives: agile requirements misunderstanding

Santa’s Workshop Goes Agile!

Posted on by
2

Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production.  Santa sighted a number of reasons for the change, among them:

  • Increasing need to be first to market against growing competition.
  • Better collaboration between kids’ toy lists and toy developers.
  • Reducing the risk that kids don’t get what they want.
  • Increasing quality and accountability in toy development and delivery.

According to Santa, “We’ve analyzed this decision for some time and  it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year.  Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”

The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.

When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum.  It’s well known, proven, and being used in some isolated corners of our workshop today.”  Some muted ‘boos’ could be heard from the audience.

Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later.  That development confirmed for some that Rudolph was next in line to take over The North Pole.  Rudolph was on hand to comment to reporters after the announcement:

“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players.  Look, what’s important here is that we get to done. I have a nose for this kind of thing.  I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away.  But, one step at a time. I expect we’ll have a more detailed plan in May or April.  Talk to me then.”

Reactions among the North Pole elves was varied.  One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision.  He wasn’t on board at all.  Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it.  When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies.  Then the Yeti put his foot down.  I think Santa knew what that meant.”

Others, like a younger elf woman, had a different opinion on the switch to agile:  “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum?  I mean….from what I read XP is way better and more applicable to our environment.  I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”

Still another view was held by Donner, “What about Kanban?  No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there.  I think there’s going to be a power play here between Santa and Rudolph.  It’s a battle that’s been brewing for centuries.”

“Give me a break. Agile?  Really, let’s knock off the buzz and hype.   So we goof up on a few thousand toys out of the billions we make a year.  How’s agile gonna solve that?  I don’t get it.  I guess I’ll ride it out and see where this goes.  But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands.  I don’t think that’s what Santa wants.”  said Blitzen.

Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.

Mrs. Claus had this to say: “Rudolph is very bright.  I know he’ll make this work.  He knows where he’s going.”

Strangely, the Yeti, was not present.  But his footprint could be found in the comments that others made.

Outsiders also came to hear the announcement.  The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow.  He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others.  His competitors have real advantages in local sourcing, customer relationship management, and technology.  Santa just hasn’t kept up and now it’s time for a radical change.   I don’t think anything he’s doing is going to change our approach.  We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”

The Easter Goose has the other 1.8% of the Easter market.

Merry Christmas agile community.  Enjoy your holidays, stay safe, and as always….take care. 😉

Advertisement

I’m Skeptical on Agile – Sell Me

Posted on by
2

Introduction

This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism.  CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.

On Being Skeptical

As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis.  Their message is honey in the ears of the right executive.  It becomes even sweeter when you consider the economic climate that many businesses are facing today.  There is opportunism here and it would be well advised to vet any agile coach.

How do I know an agile coach is worth the money?

I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.

Weight Coach 1 Coach 2 Coach 3 Coach 1 Score Coach 2 Score Coach 3 Score
Number of Projects Managed 3 2 17 3 6 51 9
Years of experience in SD/AD 2 5 24 7 10 48 14
Highest Budget Management Experience ( 1 = true, 0 = false ) 1 1 1 0 1 1 0
Number of References Validated 3 3 8 1 9 24 3
CSM Certification ( 1 = true , 0 = false ) 1 1 1 1 1 1 1
PMP Certification ( 1 = true , 0 = false ) 1 0 1 1 0 1 1
FINAL SCORE



27 126 28

So let’s talk through this matrix a bit.  First, I give pretty heavy weighting to experience here.  In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.

We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references.  The key word here is “implemented”.  There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.

Budgetary management experience, in my opinion, is essential.  If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail.   The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process.  Why?  Agile techniques profess delivering software in iterative cycles ( every 2 weeks ).  If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:

  • Don’t do that functionality.
  • Postpone it until you do have the capital available.

This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable.  If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.

Certifications show learning of theory.  I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery.  They should understand and know agile as well as more traditional management concepts and techniques.

Lastly, you should realize that agile adoption is not just a function of the agile coach.  The organization needs to be willing and able to accept the changes agility will introduce.

But my current process works, so why should I switch to agile?

If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop.  Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project.  His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.

project-types

What are the benefits if agile is applied to the right type of projects?

Better Risk Mitigation – Agile methods emphasize iterative delivery of software.  A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis.  Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.

Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally.  This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.

Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile.  The developers have a direct line to the customers.  This continuous feedback loop usually leads to better communication and understanding between the team and customer.

Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project.   An adjunct to this is an increased sense of pride in their work and kinship with each other.

What do I need to watch out for when adopting agile?

Cultural Shift – This can’t be under weighted.  Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:

1. Development team and customer working together.  Meaning other managers and IT leadership have a de-emphasized role.  Your risking attrition by some of your better players if you ignore this.  Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.

2. Team stepping up and coordinating activities among it’s members.  This is normally done by a PM or Dev manager or even a senior technical leader.  Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects.  For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.

“Documentation is not needed”  – You may hear this from some agile coaches and theorists.  The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense  for your project.   Some of us have regulatory and legal reasons for documentation.

Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends.  By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered.  There are the pragmatic agilists and then there are the agile zealots.  Watch out for the latter.

Summary

Benefits can accrue from agile methods.  These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers.  As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.

Requirements Documentaries – A Recipe

Posted on by
2

Introduction

In previous posts I’ve talked about how written requirements are on the decline and how our development methodologies and practices, at least in part, are constructed to hedge the risk of misunderstanding requirements.   As an outgrowth of those posts I’ll talk here about my vision for Requirements Documentaries as an alternative to written requirements and user stories.  I hope by the end of this post a formula will emerge for crafting video based user stories into a persistable set of requirements documentation that captures much of the context around a project.

Preparation and Coaching

How do you prepare the team for video recording?  While the discussion should be as open and natural as possible:  some coaching should be required here.  Meetings of all stripes tend to deviate from their course and sometimes into topics that are not appropriate for the organizational culture.  While these things can and should be edited out for the purpose of requirements documentaries; the team and customers should receive coaching ahead of time on how best to present their views and what topics/situations to avoid.

Other good tips should be included like: speaking clearly and loud enough for everyone to hear, avoid bad behaviors ( picking nose, tapping on the table, etc ).   We want it to be natural, but we also want it to be professional.

Tools

I believe this is a simple, cost effective set of tools that would serve as a basis for delivering requirements documentaries.

  • Whiteboard(s)
  • Wiki or requirements gathering tool ( Jira for example ).  A tool that can track versions.
  • High quality video camera(s) with sufficient battery life and backup batteries.
  • Digital camera to capture whiteboard sessions.

The Role: From Requirements Manager to Producer/Orchestrator

The role to facilitate requirements documentaries requires some new skills.  I’m calling this role “Producer” or “Orchestrator”.   But I don’t want everyone getting caught up in the title here.  It’s the skills and abilities of this role that are important.  Those are:

-Video production:  a solid understanding of digital video technologies ( hardware & software ) is important.  But additionally the person should have some training/understanding of how to make a documentary.  This would include how to edit the videos for applicability, ease of understanding, and dissemination to a heterogeneous audience.   Furthermore, this role would understand lighting, how to stage a scene, and related concepts in film/video production today.

-Facilitation & Coordination:  any good requirements manager today has to have some level of facilitation and coordination skills.  This will be instrumental when discussing the requirements, but also important in getting the right folks together to produce the documentary.  Discussions could veer off course, and it will be important for the orchestrator to guide the group back to the topic so as to make the video relevant.

-Detail Oriented:  goes without saying, but with the video medium, details may need to be clarified through, what I’ll call, adjunct clips and whiteboard captures.  So attention to detail doesn’t change, but the mediums of collection and dissemination may pose challenges for a traditional requirement’s managers.

-Organized:  just like today’s requirements the videos will need to be stitched together in some kind of wiki and organized in a manner that coincides with the software release.  Any adjunct items ( whiteboard captures, additional videos ) will need to be issued as modifiers to the original video.  In addition the orchestrator will need to keep his meetings, resources, and notes well organized.  More preparation may be needed to gather requirements in this fashion, but the benefit will be the greater context it brings to the developer’s work.

-Creative:  a little creativity to make the videos more enticing and “watchable” would be valuable.  However, we need to be careful here.  Too much creativity and the videos become more of a movie than a documentary.

-Provacateur:  a good requirements manager today thinks through the questions and challenges those in the room on their assumptions.   We still need this skill and it becomes even more important with video production.   Unless we want to issue continuous sets of adjuncts after each requirement documentary; we’ll need to flesh out as much as we can up front.   Please note, that I’m not suggesting BDUF here.  We can have 5,6, or however many requirements documentaries we need to form a release, but each of those main documentaries may have many adjuncts that clarify or modify anything missing in the main video.b

Method & Utilization

The process below could be done in an iterative or waterfall fashion.  It should be methodology agnostic.  My recommendation would be to start using this on a small, non-critical project in your enterprise.  See how it works and decide how to scale it from there.  I see this as a technique pattern for situations where your requirements may change frequently, have a complex and intricate data domain, or your team is global.  Lastly, I do realize this process is fairly basic……my intention is to start high level and as we see what works/doesn’t work we iterate back through and add more details or changes.

Potential Issues

Fear of the Camera – This is probably one of the most difficult issues.  Some folks have trouble speaking up in meetings…let alone in front of a camera.  So a sufficiently skilled orchestrator should recognize when this is occurring and attempt to bring that person into the conversation or, if completely unwilling to talk up, the orchestrator should pull that person aside, after the meeting, and have a candid discussion about whether they would like to continue participating.  It may be necessary to get a proxy to stand in for him/her.

Change – Using requirements documentaries is a big change in format.  It won’t go smoothly at first and that’s why I recommend approaching it on a small non-critical project at first.   Work out the kinks, and the issues with a group that sees the potential benefit.   Use all your change management skills and recognize the loss cycle associated with any big change.  Some may see it as opportunity, and yet others will see it as a threat.

Equipment problems – one of the reasons I stress using 2 cameras ( video and still ) for recording the requirements events:  Murphy’s Law.

Legal, Organizational Policy Issues – in some countries and companies recording by video is against the laws or corporate rules.  Check with your counsel before embarking on a project using a requirements documentary.   Legal representatives and corporate leaders who see value in this method may need to sit down and amend rules to allow this form of requirements gathering.

Politics – Recording things on video is a way of preserving the context around the requirements in addition to the actual meat, logic of the system.  It’s intended benefit it to preserve for future team members and current team members the mood, background, motivations, and reasoning behind what they are building.   This is the ideal side, but there is a less rosy edge to this.   Politics arise in almost any company, and documenting decisions on video could open the door to misuse for devious ends.   A company’s leadership embracing requirements documentaries should recognize this and put controls in place for those seeking political gain from manipulating the format.

Summary

Requirements risk exists on all projects to a greater or lesser degree.  The intention of this technique is to help mitigate that risk and provide continuity through time for a system’s definition.  I don’t suspect this will alleviate all requirements issues.  I’m too jaded by experience to think there are panaceas to every problem.  But there is some good evidence in the world of psychology and Hollywood that motion pictures are more memorable and understood more easily/rapidly.  You can see this for yourself.  When you left the theatre after seeing “The Green Lantern”  did you not understand it?   Was it totally lost on you?  Now what if I drafted that movie into a requirements document?  Logic aside…my hope is that we can catch our requirements gathering process up with the technologies that we have today for gathering that information.   If you try this technique….feel free to comment and let me know your experiences.  I’ll be anxious to hear them.


Agile or Waterfall — Aren’t We Just Struggling With Requirements Understanding?

Posted on by
1

Who is this article for?

All software development professionals will find interest in this article, but those managing, crafting or analyzing requirements may find the most interest.

Introduction

Why is so much ceremony needed around software development?  Regardless of the methodology there is a great deal of meeting, clarifying, verifying, demonstrating, and checking.   If you came from another planet and watched how we develop software you’d come to the conclusion that we don’t know how to communicate complex abstract ideas into concrete reality.  And we don’t. To be sure, we’ve tried:  detailed specifications, UML diagrams, use cases, user stories, and just plain discussion.  All of these are incremental changes to a better requirements landscape, but fleshing out our software needs still takes considerable time and effort.

Process and Methodology as Requirements Risk Mitigation

BDUF ( Big Design Up Front ) was the waterfall method to define requirements.   It was a way of saying….”Let’s get everything straight BEFORE we start the expensive process of coding and testing all this.”    It’s logical, but makes the broad assumption that people will know what they want and deviation from the initial plan will be minimal.   There are some projects where this is a very safe assumption, but not always.

Agile capitalized on this fault and said “You can’t know everything up front, so just get started and course correct along the way.”   Does this mean that agile projects always succeed? No.  It means that they allow adaptation to change.  Projects where innovation is important or where the product owner is unfamiliar with developing software naturally make good candidates with Agile.  But its pricey and if you don’t need all the involvement…..then going back to waterfall might be a good option.

With both methodologies you see an attempt to address the real problem:  understanding and materializing requirements so that we get exactly what we want.   The abstract nature of software means we’re collectively imagining what it could and should be.  But we haven’t found a silver bullet for this type of collective dreaming.

Communicating and interpreting our desires is not as easy as it seems.  Some of us are good at drawing pictures…..but most of us aren’t.  To mitigate the possibility that we’re not going in the right direction we’ve invented these elaborate software processes ( Waterfall & Agile …..and the pragmatic others ) to keep our collective minds on the same path to vision creation.

Are  There Better Ways?

Even with these processes we still end up in projects where we hear these things said:

“Oh…that’s not what I meant.  It should do this…”

“No, no,no….you didn’t understand what I was saying. “

“That wasn’t the requirement.  Read it again….I built what was asked for.”

“Yes. I know she said that….but what she really meant was…”

So, software requirements are still an error prone bottle neck in producing the product.  If we hope to make software development better;  then we must get better at this.  In paraphrasing Eliyahu Goldratt in The Goal: You can only run as fast as your slowest player.  That player for software is requirements gathering, analysis, understanding and verification.

Looking outside our field, other industries, who’ve been around longer and develop complex systems too, have similar challenges.  What do they do?

Design –  My wife is a talented contract graphic designer for a local St. Louis firm called Kuhlmann-Leavitt.  They’ve won many awards and have very satisfied customers.  All this despite the nebulous, subjective nature of graphic and three dimensional design.   How do they do it?  The design field is interesting.  They don’t estimate anything.  They simply ask that you hire them for your artistic work and set a budget.  They’ll do the best design work they can for that money.  No more, no less.   So right away the budget issue is taken out of the picture.  Lastly, they don’t ask for detailed requirements,  just some idea of what you’re looking for.  You’re not hiring Kuhlmann-Leavitt to build.  You’re hiring them to create.  My bolding hints at the nuance.  Considerable authority and autonomy is given to the designers.  This is just expected.  Software development relies much more heavily on ‘domain experts’.

Manufacturing – In the manufacturing world BDUF could be rewritten to be MDUF ( Massive Design Up Front ).  Not only is the product designed way up front and in detail, but the process and mechanisms to build the product, which aren’t always the same, are designed up front too.  Before the real product even undergoes one production run…many small demo runs are carried out.  The results are stunning.  Once the product starts rolling off the assembly line its produced to exacting tolerances.  It mostly fits the requirements of marketing and can be replicated thousands of times over.

Construction – We’re talking about unique, one of kind construction here.  Not production line assembly of a subdivision.  This one-off building is, to my mind, the most similar to software.  Some requirements come from regulations and building codes.  Others come from the purchaser of the structure.  There are multiple stakeholders.  Requirements are digested, and then artifacts are created.  A series of mock-ups are assembled and based on this a cost estimate is created.  Even with all the up-front planning there are always “gotchas” and changes that are thrown into the project.

In all three of these examples the end product is visual and intuitive which helps with requirements understanding.  A picture really is worth a thousand words.  Software, as workflow, data and creative design is more abstract.  We’re trying to craft ideas and concepts into something that is somewhat tangible.  Certainly the user interface can be mocked in a similar way and there is great value that comes from the discussions around this, but a sufficiently detailed workflow and data set always serve to vex our attempts to provide clarity to requirements.

What’s next?  What can we do?

Here’s part of our problem:

1. We discuss the first iteration of requirements with our product owners.  The person leading that discussion is gifted in facilitating this.

2. From this meeting, the requirements are crafted into user stories.

See it?  We just lost all the context, emotion, body language, nuance, and reactions by everyone else by drafting something into writing.  I don’t care how good a writer you are…you can’t replicate the requirements conversation.  So why do we try?

The next problem comes when you ask each person to interpret the written user stories.  Hopefully each team member was present for the conversation so they could somewhat remember what transpired.  But, even with attendance, the human memory is frail and human perceptions, bias and concentration vary. Each person may see and read the requirements slightly different.  In short there are too many lenses.

Rather than try to abstract requirement conversations into another form ( writing ) or create even more abstract artifacts ( UML, Use Cases ) we should seek to record them via video, photographs of whiteboard drawings, and publishing all this to some kind of requirements wiki or blog.  Doing this for each iteration review, iteration planning, or project meeting would surely capture a much more complete document of the project’s scope, changes, stakeholder motives and historical background.  Further, it would exist in perpetuity for future developers to watch……just like a movie or project documentary.

Summary

I do realize that the suggestion to move towards requirements documentaries may be fraught with organizational, legal, and other challenges.  I would never suggest that change on this scale is easy.   But I do believe there is productivity savings to be found here.  As I hinted in Decline of Written Requirements  I think we’re using 20th century tools and techniques to gather and analyze requirements in a 21st century world.  To lessen the need for process mitigation of requirements risk we may need to refocus and leverage our new tools: cell phone cameras,  high quality digital video, wikis, and blogs.

Decline of Written Requirements

Posted on by
4
Introduction
Requirements managers, project managers, and business analysts will find the most interest in this article. Developers will find a nice challenge at the end.  🙂   In this article, I attempt to show that written requirements are no longer necessary….and a new tool, using new media….is necessary.
Why did written requirements fail us?

Requirements gathering, analysis and management has never been easy.  It’s hard work filled with nuance, half-truths, mis-interpretations, ulterior motives, impressions, imagination, emotion and misunderstanding.  It’s vision crafting.
Getting everyone on the same page to a clear and sufficiently detailed model of the proposed system requires a conductor with the right skills.  Too critical to be ignored, a lack of depth in this area can doom a project.
To help codify that vision the software industry quickly turned to documentation and documentation standards.  But, written requirements have proven to  be an inadequate fit with the abstract nature of software and these flaws became apparent:
  • “That’s not how I read it”
  • Versioning Changes
  • Big complex software = big complex requirements = never read/hardly understood
It was realized by a myriad of software professionals that relying exclusively on the documents and omitting en
gaged conversations to clarify the written word was a mistake. But….spoken requirements and conversations have these flaws:
  • “That’s not what I heard or understood.  That’s not what I remember.
  • Hallway conversations, informal clarifications that aren’t heard by all parties.
  • Complex requirements can’t easily be remembered, conveyed through conversation alone.
  • Change management is non-existent.
User stories attempt to blend the spoken and written worlds and emphasize the continuous interaction between customer and software development team.  They rightfully restored the need for conversations and engaged business domain involvement and got us away from the never ending refinement or versioned requirements books.  They get us closer to where we need to be.  But, they still miss the mark.  Some flaws of user stories and their crafting are becoming apparent:
  • Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
  • An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
  • It’s a fine line.  How much to write?  How much to discuss?  Too little and the story is worthless.  Too much and we’re back to writing all our requirements.
  • Complex business domains and logic need to be documented in detail.  A simple story ( or many simple stories ) with acceptance criteria may not be enough.  Think about requirements for the Boeing 787 flight control system.
  • User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
Where are we headed?

With the proliferation of digital video, cell phone cameras, webinars, social media, and whiteboards we have a new set of building  blocks to create the 21st century requirements management tool.  And that is my challenge to the community.  Build it.  Use these pieces to create a new tool for managing requirements that further reduces the risk of interpretation.  Here are some advantages I see:
  • The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
  • Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
  • Whiteboarded artifacts could easily be recorded and saved along with the video.  Adding to a thorough documentation of the conversation.
  • While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
  • Productivity in requirements gathering  and recording could potentially jump helping out the entire software development process.
If you feel you’re up to the challenge…:)….then contact me ( chris@effectivelogic.biz ) and I’ll give you further guidance requirements.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.