We Remembered Not to Dive Too Deep Too Soon

While reading “Remember to not dive too deep too soon” by Derik Whittaker, I was reminded of something that happened at work today. We were going over a couple new stories in our backlog and needed to assign points to them.

Before adopting Scrum a couple of months ago (versus the Slam Dunk Model), we would have had a task that required somebody on our team to:

1. Install a 3rd party component that logs what people are searching on (and not finding).
2. Configure the log server so that the fields we’re interested in are correctly parsed out.
3. Upload this data into a SQL Server database so that reports can be run against it.

This isn’t an awful task by any means, but there are a lot of unknowns

in this list. The first being the one that we’re stuck on now, it’s

installed, but not creating the files correctly. It will likely take

one of us to open a support ticket with our vendor and wait on them to

help us out debugging the issue. We can’t estimate this very

accurately, not having dealt with their support team very often. This

would have been a tough task to estimate and we probably would have

guessed too little in the beginning.

Now that we have things like estimation meetings, a backlog and points

for our estimates, we’re not only getting things done on time, but

we’re finding better ways to do them. We’re not so often stuck with our preconceived notions of what we think it will take to get it done.

I didn’t intend for this to be a discussion about Scrum, but I wanted to provide another reason for Derik’s post that “diving too deep” into the details of a feature/task is bad. We used to be, and sometimes still catch ourselves, talking about all the low-level details of the code and what kind of tools we’re going to use. This task of logging search terms that are not found was worded very well as a story that provides value. With the story, we discussed other alternatives that would provide the value that the story was looking for; it wanted to provide only not found search terms. This didn’t mention anything about opening support tickets, writing an application to parse a file or the like. We decided we could probably do this fairly easily by simply creating another log4net appender. Boom! Done.

I think the discussions are good to have, but if you’re getting too detailed like Derik mentions, who cares what the schema of the table is as long as it is providing the client with the value for which they’re asking. Even though it’s fun to talk about, skip the low level stuff.