Blog of a Boston-based IT Consultant

User Stories are very alluring to a contemporary PM, because the impulse to break them down into requirements is almost unavoidable and provides immediate meat to sink teeth into. In the more Agile-minded PM’s mind, there is the impulse to break User Stoies down into tasks and estimate against those tasks. You can start off with Context Diagrams or any number of initiation documents, but User Stories are the most flexible and when beginning a task that will require flexibility, this makes sense to me. Previously, I detested the idea of User Stories. I still do, but the key is the context. What kind of Client is it and what kind of project is it?

Each task has an associated total number of hours (estimated, estimated with multiplier, actual, remaining, and others depending on the document). Each task is part of the feature that the User Story will deliver. You add all these task estimates up, and you have your total estimated hours for a given feature. Or so it seems.

On it’s own, this will go to Development and often be addressed task by task. With a traditional Development team, taught to code not with FDD or TDD in mind but instead to just “code”, each feature will be built by building the backend first, then probably the UI, and then the stuff in the middle (for example). It is all of this, then all of that, and then we are done if UAT goes well.

I believe in proof of concept. In the aforementioned routine, it is very possible that it will not be until this feature gets hooked up that some oversight is revealed or an issue rears it’s head. There is the concept of the Tracer Bullet. I did not come up with it. It is really a munitions term. It has been applied to sofware development by a gentleman named Dave Thomas as it relates to the Client engagement, but more academically, an early iteration - a working prototype. The point of iterative development, RAD, RIP, and client-involved JAD is to get feedback and really, have the client actively involved and correct issues before they are too costly to address.

Ideally, we would eliminate all risk of this on paper, through paper prototyping or UML or other (probably Visual) requirements techniques, but the quicker we can get feedback, the quicker we can augment or move forward. It can be very frustrating, especially with truly novel ideas, but this is where passion and development have a lovely and magical time together. Get a passionate Dev on a project with a passionate Client and have a passionate Manager in the middle and there is a really cool synergy that happens. People learn from each other, and they take those lessons with them after the project is over.

Instead of breaking features or functionality down into requirements, and then development tasks, sometimes you can just jump in and do work. This takes a team with good communication skills and a Client with real interest in the project. Formalities and ceremony take up a lot of time. They cost a lot of money. PMI has made a fortune on selling the idea that they are necessary. They are not.

What is necessary is momentum and guidance. If you are going to get from here to there, you have to start moving. Planning is great, but Plans (as in the GANTT prototype) are ephemeral. Software is not construction, though several methodologies have a “Construction” phase - maybe to give a warm fuzzy. Work does actually happen, but people are realizing that with something like software, where you start with nebulous action items, it is important to not assume too much about the Whole, and instead feel your way along as you go. Software is tactile as much as it is cerebral. People have to *use* it. Usage minimizes waste as well, because early feedback is feedback against minimal investment. Get users using the software. See what they say. Take a few well-informed risks (you are paid because you are an expert - remember that and don’t be afraid of it like some are) and let the Client tell you “no” if they don’t like it. At least you will know before the delivery date comes that something is horribly wrong with the way you built the Shopping Cart or whatnot.

Wireframe processes are a neat concept. The difficult part is not succumbing to the urge to fill in the gaps too early. At least, for me, that is the difficult part. I love to deliver. Part of delivering is getting there, but yeah, I really dig delivery.

Best,

Josh

Project Management | RSS 2.0 | Comment it , or trackback this post.