Detailed Estimates Are Often a Waste

Some people believe the best way to estimate a project is to produce detailed requirements and design documents for every feature before writing a line of code. It sounds professional. It sounds thorough. In practice, it usually turns out to be wrong. Requirements change. Priorities shift. The detailed estimate you spent weeks producing becomes irrelevant halfway through the project. That effort becomes wasted inventory – time and resources that could have been spent building something useful instead. ...

19 July 2010 · 1 min · 106 words · Shafiq Alibhai

Project Scope and Success

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two. I’ve learned this the hard way. Every project starts with an ambitious list of features and an optimistic timeline. Reality intervenes quickly – resources are tighter than expected, technical problems emerge, and deadlines don’t move. Cutting scope feels like failure. It’s the difference between shipping something that works and shipping nothing at all.

17 July 2010 · 1 min · 81 words · Shafiq Alibhai

Scrum in 8 Steps

Scrum breaks a product into small pieces (backlog items) and works on them in short iterations (sprints). Here’s how it works in practice: 1. Prepare the product backlog. List the features and requirements. Involve stakeholders to prioritise. The product owner is responsible for the vision and goals. 2. Estimate the backlog. As a team, give a rough estimate for each item. Planning poker or t-shirt sizes work well here. 3. Plan the sprint. A sprint is a fixed period – usually one or two weeks. In the sprint planning meeting, decide the duration, goal, which backlog items to tackle, the tasks for each item, and the hours per task. The result is the sprint backlog. ...

22 March 2010 · 2 min · 277 words · Shafiq Alibhai

Restarting a Project from Scratch

Every programmer knows the urge: scrap everything and rewrite it from scratch. It’s not that the existing code is bad. It’s that it’s hard to understand. Reading code is harder than writing it – you wrote the new code in your head, but the old code belongs to someone else (or to past you, who might as well be someone else). This is why every developer on your team has their own favourite way of splitting strings into arrays. Writing a new function is simpler and more enjoyable than learning how the existing one works. ...

8 March 2010 · 1 min · 106 words · Shafiq Alibhai