Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Thursday, June 25, 2009

What does "requirements sign-off" mean in agile?

I was recently working with a cusotmer on a project using an agile methodology. The organization was moving towards trying to do most of their projects in agile, so the nature of this is that they have a lot of non-agile pieces to their methodology still in place. We were cruising along in defining requirements and development was well into the first sprint, when the project manager told me we had a target date for the requirements to be signed off.


Wait a minute! Hold your horses folks! Sign-off? In an agile project?


I took it upon myself to remind her of the development methodology of choice for our project… and that she was asking me about sign-off in a methodology where it doesn’t really make sense…. one where the users have the right to prioritize whatever features they want in the backlog at any time. So if they forgot some features during our elicitation process, then that’s ok, they just need to figure out where to put it in the prioritized backlog, realizing something else may drop off. She laughed immediately reassuring me she hadn't lost it and that she understood completely, but the corporate process required this! So we began the discussion of what a “sign-off” would mean to us.


In the end, I think we got pretty creative with it. We did have lots of requirements in the form of user stories and other models like process flows, state tables, etc. And we were working closely with the users to elicit and review them. So what we asked them to do was to “sign-off” that at that moment in time, there were no major requirements missing, that they knew about, and there were no major issues with what we’d written down, that they knew about. The key is this means that they did in fact look at them, they participated in the activity and so development is not developing a prototype of something too far off basis. But it also keeps open their right to realize something new they need after they see it, think about it, sleep on it, or whatever.


What I really like about this is approach is that it doesn’t force anyone into a corner where they feel like they are signing away their life over a massive requirements document that they barely understood or that they are signing on a dotted line to say they are mostly perfect and got it all the first time around. So more or less, I think our version of sign-off allows the spirit of agile methodologies to prevail still.

Labels: , , ,

Requirements Defined Newsletter Bookmark and Share

3 Comments:

Anonymous Ellen Gottesdiener said...

Thanks for the story, Joy. good issue to bring up.

Your experience shows how working with "non-agile" groups/folks/thinking can cause falling into traditional/waterfall practices.

Having to do formal "sign-offs" practice can potentially inhibit making the transition to agile - and is also is a agile transition "smell".

Questions to ask folks are:

Is document sign off an event, task, or deliverable?

What is value of the sign-off?

Clarifying these questions might be helpful.

(i wonder if the people-wanting-sign-off have a trust issue, need some documents for someone else, are fearful of what would take its place, or should be involved in demos/reviews to 'sign-off' at the time of delivery at iteration-end.)

One way to address "reqts sign- off" is to include reqts documentation as part of the "doneness" (conditions of satisfaction) for iteration stories.

If they want to, they can also include having that signature. so they are 'signing' off documentation in small chunks, an iteration at a time.

Yet another option is to make reqts documentation stories (or a story) in the backlog.

This means it would need its own doneness, such as the format and format and signatures needed. The customer thus has to rank that story along with others, making it all transparent.

~ ellen
www.ebgconsulting.com

6/27/2009 4:03 PM  
Blogger Joy said...

Thanks for your comment Ellen - I like the practical tips to try to apply.

7/06/2009 3:54 PM  
Blogger Unknown said...

I think that even in an Agile environment the concept of signoff can fill a valid function. Agile tells us to “embrace change” but the concept of change only exists with respect to a reference point. Even within a team where there is close communication, people can have different interpretations of current plans and status. One person’s “change” can be what another person thought was already agreed to. Without a reference point everything can become in the words of Piaget “one great buzzing, blooming confusion”.

Typically we think of sign-off as implying some sort of contract, which definitely goes against the Agile grain. However, if you position a sign-off as a lightweight ceremony acknowledging that (in mall parlance) “We are Here” I think it’s fine. Just because “We are Here” today doesn’t mean we can’t be somewhere else tomorrow but at least it ensures a common understanding and point of reference.

Nanette Brown
NoteWell Consulting

7/29/2009 9:22 AM  

Post a Comment

<< Home