I’m afraid we’re going to have to disagree on this. I used to be a proponent of modeling every use case/user story, and then keeping the model up to date, so we knew the design of every use case, which classes it involved, and what methods. Over time, we had to let go of updating all those models after someone changed something, due to the pressure of delivering more to the customer, and a funny thing happened: it just didn’t matter that the models weren’t up to date: nobody used them.

Sure, it’s a good idea to make sure that the features you want are represented as user stories, or use cases, to make sure you don’t forget something important, but that can be done in a very lightweight way (keeping track of themes or epics, and then making sure there are stories for them, for instance), and that’s not what I mean by complete traceability. Traceability to me is being able to refer to a detailed model for the story (typically class and sequence diagrams), and knowing that the model is correct. That means that someone kept it up to date, or rather that everyone who worked on the system did.

The value of producing a model for a story or a use case is in thinking about how you’re going to deal with the requirements, and that can be done at a whiteboard. If it’s put into a formal modeling tool, in my experience it’s seldom referred to afterward, sometimes because it’s no longer correct (because nobody updated it), sometimes because it doesn’t cover the right level of detail in order to be useful, and sometimes because it’s just easier to read the code.

In my experience, which is considerable after over a decade working for large companies as a consultant, here’s only one that got any real value from complete traceability, and they were filing FDA paperwork for medical devices, so it was a requirement for them.

I appreciate your comments, even if we disagree,

Keith

Knowing what is the right thing to do is necessary but not sufficient. Necessary and sufficient is doing the right thing the right way… Then, it may provide “good enough” value. Hard to believe that no one has got any positive experience with traceability.

Thanks,
LevA

“Just enough” is going to be different for every team, and for each activity you undertake, so it’s not possible to give concrete guidance on how much is just enough.

That’s the reason I suggest that we ask “why?” If we ask “who needs this, and for what? Is this the best form for what they need?” we stand a better chance of finding all that make-work we do “just in case.”

We’re always going to be asked to do more than is “just enough” but at least if we’re asking the questions, we can try to keep our focus on providing just enough.

Thanks for your comments!
Keith

Yours, Petri

So often agile/scrum becomes we can do whatever we want and change at any time. That just doesn’t work. That is a formula for getting nothing done, or something done poorly.

Admittedly, sometimes major course corrections are required mid-way through a sprint, but with good communications, and sticking to short sprints those problems can be managed without falling into too much chaos.

Melody

Yes, as you point out, companies, and teams in particular, need to be careful not to mistake a free-for-all for using agile. Agile, and Scrum, give us just enough structure to work effectively without creating a bunch of make-work.

Chaos, on the other hand, robs the team of self-direction (because they never know what they’re going to be doing), doesn’t allow for any sort of predictability, empirical or otherwise (since we have no backlog, and thus no way to measure), and I think has no good way of evaluating all the priorities the team is being asked to satisfy (because we can’t see them all in one place without a backlog).

I’m not being critical of agile here, I’m being critical of chaos-called-agile, because it really gives agile a bad name.

Thanks for your comments!

- Keith