Feature requests in the middle of iteration [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

We are developing our project in the following way:

1. Feature request list
2. Estimation
3. Coding
4. Testing
5. Tagging version 1.x

One iteration usually lasts for 1 month. But sometimes we get immediate requests from project manager - "Guys we need this small feature BADLY!" Here starts something I do not like:

1. Implement in tag
2. Implement in trunk

How do you deal with inter-iteration feature requests?

Thanks.

Answer 1

1. change the code on the trunk
2. merge the change from trunk to the last release branch (cherry-picking)
3. create a new release from the release branch

If you do not have a release branch, you can create one afterwards with

svn cp ^/trunk@1234 ^/branches/release-20130621

where 1234 is the revision of the last release.

Answer 2

An option you have is to reduce the length of your iteration. That way the longest they have to wait is two weeks.

When the manager wants to introduce a new feature, it is simply included in the backlog for the next iteration. Is it really important enough that they need it in less than two weeks? Aside from critical security issues or fatal crashes I doubt it.

Halving the iteration length should not double the amount of overhead. If it hurts, do it more often.

Answer 3

Ignoring your project methodology for a moment, the end state of your repo after such a feature is delivered should be:

1. You have a new tag with an incremented version number, and the difference between it and the previous tag is the new feature.
2. The main line of development (trunk) includes the feature too, such that new branches get the feature, and existing ones will get it next time they sync up with trunk.

How you get there depends a bit on your repo layout and its conventions, but here are two options (which appear to correspond with what you don't like):

1. On a new branch off the current tag (or an existing release integration branch that clean), complete the feature/bug fix, create a new tag and release, and merge the tag back to trunk. Good option since it minimises risk that unwanted changes are released with the bug fix. The merge back to trunk might be difficult if much has changed.

2. Complete the feature on trunk first, cherry pick it to a new/existing clean release integration branch, tag it and release it. Good because others get your feature/fix earlier. The merge to the integration branch might be difficult which might slow down the release.

I think Option 1 is best since it will generally be quicker to release since any merging is postponed until the changes are ported back to trunk, and there's less risk of unwanted changes leaking into prod.

As far as your project methodology goes, if you are to accommodate the feature, you must either;

1. Reduce scope of current iteration
2. Delay release of current iteration
3. Get additional resources (developer/s) or do overtime to build the feature

... Or some combination of these.

Answer 4

If possible, we are trying to move change request to the next iteration. If not possible - we are preparing ETA and milestone/demo/release date shifting.

All that we need to warn customer that feature request in the middle of iteration is always a bad thing. When he is aware, he is expecting such state of affairs.