Working software over documentation is often taken as, we should only write code and not waste time on documentation. It is boring, and out of date before it’s finished being written. I hope to argue through example why you shouldn’t follow that advice.
You’ve been given a brief, we need a system that tracks stock and reorders stock when needed. The first two questions you are going to get asked are: is it possible, and when can it be delivered?Team A
Team A thinks it’s pretty simple, if you have less than x units of stock left reorder the stock and the rest is integration work. They estimate 1-2 months.Team B
Team B tries to outline all the possible work required.
Team B: How do you plan stock currently?
Client: We look at last years data and try to order that much, to match our ratios of t-shirts/jeans we want to buy this year.
Team B: Do you currently enter those ratios anywhere?
Client: I don’t think so…
Team B: Haven’t we already discovered our stock data is only 60% accurate in stores, doesn’t that make last year’s data unreliable?
Client: Yeah but that’s another project being worked on, we also want to do this.
Team B: We have warehouses and stores with different stock pools, is this just for warehouses or stores as well?
Client: Stores should never be out of stock, and warehouses should always have enough inventory to replenish.
Team B: How should we decide which store gets the stock if there is not enough for the warehouse to replenish?
Client: The store that will sell the most should get the stock… I don’t know how you would do that, probably take last year's data, and also the previous weeks should come into it somehow, also we have special events at some stores we will need to mark where they will need extra stock.
Team B: Okay let’s talk about this more but I’ve noted everything so far. The stock accuracy project should go before this to forecast correctly, we also need several new views for you to plan this year's ratios and also enter special events, we will need to come up with an algorithm that decides what happens when stock is too low to replenish everything to full stock. This will take at least a year.
But wait, isn’t this the whole reason we don’t plan? After just a short conversation Team B has uncovered significantly more work, what a waste of time giving an original estimate and now they think we’re bad at our job increasing the deadline!
We need to accept that estimates are not deadlines, but they will change constantly as the project progresses. The start of a project should see the estimates as erratic and increasing for the first half of the project as we discover new requirements and uncover new blockers. The latter half of the project estimates should start to solidify, and we see a gradual decline of hours required.
Breaking down tasks will not only allow you to explore the domain and find blockers significantly earlier, you will also get much more accurate high level estimates for “build an allocation system” if you understand it consists of smaller estimated tasks such as “change x part of database schema”, “rewrite this view which no longer makes sense”. The client can also immediately see their request was not trivial, and will work on setting expectations and slimming requirements if you provide estimates for small tasks and roll them up along with this initial planning.
This doesn’t mean you shouldn’t do any work until the plan is complete, you most likely have a dev team itching to get started, but developers get depressed being asked to rewrite software on false assumptions, and clients get really excited seeing their idea come to life so early. Create a balance and culture where core assumptions are validated early around the data model and user flows, but prototype views and throwaway code are encouraged to validate ideas.
If you agree with any of these principles I would love for you to checkout Tahsk, where we are creating an opinionated project management software encapsulating these ideas.