robjam.es

I know there is a lot of developers kicking and screaming when they see this, but hear me out, as it is important for the success of your project/product and your sanity and the business being happy with you as a developer.

Lets get one thing straight; REQUIREMENTS WILL CHANGE! I cannot stress this enough. What project (beyond the most simplistic) have not had requirements change? If they changed because someone didn’t provide enough details in the first place, or the business forgot something, or the market environment has changed, or a plethora of other reasons; it doesn’t matter. The business isn’t changing requirements to piss you off, they are doing it because one of the above reasons happened and they need to make the change.

Now that you are all angry at the above paragraph, it is time for the good news; a system to make it work!

Firstly, I would hope by now that you are using an Agile process to develop software, and my solution only works if you are doing Agile development. And when I say “my” solution, its not mine at all, but just my way of implementing what Agile tells us to do.

Since you are doing Agile you are using an iterative approach. My personal preference is to take the fixed timeboxed approach versus what Scrum tells us to do which is a variable timeboxed. In a typical fixed timeboxed approach, I generally like my iterations to run for 2 weeks. This is because in the 10 working days we have, this is usually enough to have 1 day at the start to plan the iteration, and get all the story details out, the last day to get the iteration build out (although this should not take the day at all) and 8 days to drill out the dozen or so stories you have prioritised for this iteration.

This iteration release is locked. So when the business says we need to change the requirement, tell them it is not going to happen in this iteration. Whatever the new requirement is, write up the stories, and add it to the backlog and then get the business to re-priorise the backlog for the next release.

There is only 2 times that you should effect what you are delivering for this iteration, and that is when the requirement is not a requirement change at all, but further details about a story you are currently working on that won’t effect the estimate. Ie/ “When creating the login screen, we want the word ‘account’ to be replaced by ‘username’”. But if the requirement is, “We no longer want the user to login with a username, instead they are to use an email address”, this is a “We’ll have to add a new story and prioritise for the next iteration.” In this second scenario, although as a developer, you may write some redundant code to implement a username, don’t worry, all the other stuff is valid (password checks & validation etc), that it would actually be more disruptive to drop this story altogether to start something else.

The other time that a change to requirements can effect a current iteration is when the change is actually making an existing story totally redundant. ie “We no longer want to have a username/password for login, but want to just use Open ID”. In this case, if you are currently half way through the login story which is going to be a total waste of time, its time to drop it and roll back the code that you wrote. BUT, and very big BUT. This doesn’t mean that the new requirement becomes a story for this iteration, it goes into the backlog to be prioritised for the next iteration, or at best, goes in the “unplanned stories” bucket for the current release but is the lowest priority. This is slightly controversial, and that is because you may have planned to deliver 28 points in the current iteration that has a capacity of 30 points, and by dropping the login story, you have saved 5 points and consequently are down to 23 points. That is fine, if we really do save ourselves the points, we’ll get to it at the end. There is a conscious reason for doing this; mainly it is to avoid the knee-jerk reaction to adding new stories. It buys some time for the business to really think through why they are adding this requirement, and secondly, it is a way to apply a “cost” to the business for changing a requirement. I know you are all thinking that we are punishing the business, and although this is not entirely true, it is partially true, because the reality is that changing requirements is extremely disruptive to the current iteration, and its always best to continue with what has been planned.

By applying these rules, you continue to set an expectation of what I called the “heartbeat for the project”. If you are running fortnightly iterations, then everyone expects to lock in the stories during the planning meeting, and they also know that the stories will be delivered in 2 weeks, and this will be consistent. Routine is not only good for babies. It is good for all of us!!

If you have a business that is really unsure that of what they are doing (and this happens, and is quite fair, if they are still brainstorming some of the requirements), you may want to shorten the feedback loop. The feedback loop is the time you have to get working code from an iteration out for QA or the business to test and validate. So you may want to run 1 week iterations. The only thing to take into account, is that you will not be half as productive when you half your iteration cycle. This is because you still need to go through the planning cycle. Although you may be delivering 30 points in 10 days, you will probably only be able to deliver 10 points in 5 days.

But this is a sure fire way to keep yourself and the business sane and happy, by putting in a process that allows changes to occur immediately, and to be implemented in no longer than 2 weeks (or the length of your iteration).