I’ve been a fan of user stories for several years now. User stories are a way to describe a set of functionalities of an application in a way that is focused on results – it’s easy to connect to mission. An example from an events management application:
The organization should be able to create several different kinds of events, and determine for each kind of event which detailed information will be taken. Those events can be displayed in a list or calendar format. Users can register for events, and pay using a credit card.
There are many ways to describe this story – it certainly can be a lot more detailed, but what’s clear is the result of this functionality. And, of course, user stories are great for agile development process.
Developers would determine how much this function would cost (based on our knowledge of the tools we use, and the time it takes using those tools to generate this sort of functionality), and clients would know exactly what they are getting from a functionality standpoint. When this functionality is complete, everyone is happy. The developers get reasonable compensation for a job well done, and the clients get the mission-based functionality they asked for.
And it would avoid a situation which I have become recently far too familiar with – vendors who underbid projects, and then feel the need to resort not to the intent of the contract, but the letter. Everyone knows it is utterly impossible to specify every detail in the letter of a contract – sometimes letter of the contract, unfortunately, details things like fields and queries, not functionality. The letter of a contract will be, almost by definition unless based on functionality, an inadequate representation of the final result needed. In this case, no one really wins. The clients either don’t get the functionality they expected, or they pay extra for it, and they leave the project with a bad taste in their mouth about the vendors, which will only come around to hurt the vendors later.
{ 4 comments… read them below or add one }
User stories are great for keeping a project on track. It’s so easy to get caught up in details and implementation – especially for developers like me who really love sweating the small stuff. Stories are something that you can always reference as a project matures. Also, they’re easy to write and don’t require any technical knowledge – so any member of the project can say “It should do xyz”. I still have most of the stories that we started for the donor management and fundraising features of Donor Tools – and most of them are still relevant! A different developer might have solved the problems differently, but the stories gave me the flexibility to tackle the problems my way and come up with an innovative solution.
So, I am uncertain – how far does the “intent” of a contract go, and who gets to decide that? It seems the point of a contract is to solidify and document “intent,” so that both parties have a clear understanding of what will be delivered.
It is very possible (and I suppose too common) for a clients “intent” to shift as a project progresses. The contract should lay out very specifically what is expected of the contractor – this is the document by which they determine time estimates and resource needs. To hold the contractor to some expectation of fulfilling unspoken, undocumented and uncontracted intentions that the client may have is unfair. That would void the whole purpose of having a contract, wouldn’t it?
This isn’t to say that a contractor can’t or shouldn’t strive to go above and beyond. But to chastise contractors in general for not doing more than what was agreed upon does not seem right, or good business practice for either side.
The point is not to chastise contractors, nor expect anyone to do more than what was agreed upon. The point of the post was to shift some ways of thinking about what was agreed upon so that clients know exactly what they are getting functionally – they have a completed product that does what they want and expect, and the contractors get fairly paid for that result.
My suggestion was that the way that things are often currently specified leads to a situation where clients are left with results that don’t function as advertised, and need to end up spending more than they expect in order to get a functioning product.
And although I do think that intents do shift during the course of the project, it is important for contractors to track and flag those changes in intent, and be clear with the clients when they are out of scope.
I see. That makes sense, and I take your point then. I agree with you 100% on your last point particularly. A lot of frustration and misunderstanding can be avoided with good project management. Well developed user stories can go a long way toward achieving that, so I do agree with your overall point for sure.
My argument also assumes that all contractors are a) competent and b) well intentioned and I think we all know that in the real world that is not always the case. Though it is a foreign idea to me personally, I can conceive of contractors that would, through either a or b above, over sell and under deliver.
Obviously, it the the opposite of this that the competent, well intentioned contractor continuously strives for.