I am a new PM. My company uses Rally for project management. I'm not too sure if this is a standard across platforms, but in Rally you can assign user stories to a parent feature.

My team has been working through features for our upcoming release. Most of these features are complete or near completion. I have been meeting stakeholders on a weekly basis to demo the tool and have received quite a bit of feedback on what needs to be added to the tool before the release.

My question is - should I add user stories with this new additional functionality to (almost) complete features? Or would it be a better option to create a new feature and dump all the new user stories in that?

My gut feeling in the former. It puts the new functionality/user stories in the correct feature categories which is easier to track and keeps everything organized. The con is, adding new stories to completed and now inactive features may turn them into 'incomplete' features. It's like revisiting the past.

Any advice is appreciated!

  • 1
    The general rule in software is that nothing is "complete" until the day you stop using it. – nvogel Feb 28 at 8:25
  • It would help to know what methodology/process/practice you are using to build the product. Seems you are doing some sort of Agile... – Bogdan Feb 28 at 9:32
  • Is your task specifically to implement the original design brief, or what leeway were you given? – Robbie Goodwin Feb 28 at 21:04

You already have two answers to your question, on opposite sides of a spectrum, and since you mentioned you are a new PM, I think some explanations are needed regarding them.

Both of the answers are correct, depending on what approach you use for building your features. One leans towards Agile, the other towards more traditional project management. It's basically the difference between Adaptive and Predictive approaches.

The predictive approach, or traditional project management, relies on building detailed plans upfront. You figure out what you want to build, gather requirements, detail those requirements, build a detailed plan of what you will build, organize all the work needed to accomplish the goals laid out by the plan, construct a schedule, stick to the schedule, build the thing, test it, release it, celebrate your accomplishment.

This works well for some types of projects, but not so well for others. When you use traditional project management, you end up with things like the Iron triangle which involves balancing project constraints while you try to stick to the plan you built at the beginning. For building a house, or a bridge, or a highway, this type of project management is appropriate because these types of projects were done before and you have a good idea about various activities that compose the projects (although these projects also go over budget, over time, or build less than needed). For things like software, traditional project management isn't well suited for most software products. And the reason is that the nature of software development is different than building highways or bridges.

Enter Agile, which was a response to building software using traditional project management techniques. Being frustrated with how things got built in software development, some bright minds got together and created the Agile Manifesto to lay out what they thought was a better approach to developing software. Agile is a set of values and principles, a different mindset for building software. Something that right in the face of traditional project management is "Responding to change over following a plan". This doesn't mean that there is no planning in Agile, on the contrary, it just says that big upfront planning combined with trying hard to stick with the plan isn't the correct approach.

And the reason is, as one answer mentions, that users don't know what they want, and they realize what they want when they see it. So you have to build things fast, put it in front of users, get feedback, gain insight, then decide what to build next, build it fast, put it in front of users, get feedback, etc. It's no longer about a plan that needs to be respected, and when people ask for changes or new features to say "well, that's not in the plan we agreed, let's agree on a change process, where we meet and discuss if it's worth straying from the plan". This is what the second answer mentions.

Agile welcomes change, while in traditional management change is considered bad and has the negative name of scope creep, and must be avoided. This is not to say that in Agile you just make any changes that get thrown at you, it's just that you don't consider them bad (they are to be expected - simply because that's the nature of software development). Instead of trying to lay out a rigid plan upfront, when you know least about what needs to be built, and sticking with it, you just incorporate change requests and demands for new features into your approach, and rely more on prioritization than heavy planning (you plan as needed, when needed, and change direction instead of trying to stick to a direction chosen from the start).

With that being said, going back to your question, it seems you are doing some sort of Agile (you mention Rally, user stories, weekly meetings, demo) so the answer to your question is that it's not a problem to add new stories to almost completed features, simply because features are never completed, only abandoned. Adding new stories to existing features or creating new features and attaching the stories there is now just a matter of how you would like to organize your process. For the features themselves the question is if the changes are needed or not, or if the changes need to be added now or can wait for some later release (i.e. the prioritization I mentioned above).

To me it seems that you are building features with an Agile mindset, but think about the feature descriptions in a more traditional manner, as stages that you already completed and you are moving on, and don't want to come back to. You need to reconcile these two things and then you will know where to add the new stories and how to record the changes.


Requirements evolve as the project progresses

Welcome to pm.stackexchange!

You said:

I have been meeting stakeholders on a weekly basis to demo the tool and have received quite a bit of feedback on what needs to be added to the tool before the release.

This is common and natural for any software.

Users don't know what they want until they see it.

Even with good input from the users no amount of analysis of user requirements can take away an immutable fact that users only think that they know what they want. In truth, it’s not until they start seeing something, and using it, that they begin to really understand what they need. This is especially true when the software is being developed for a new idea or process that they haven’t used before.

Next, when you roll-out your application for pilot trials, you will receive more feedback from actual users. Meaning your features are never going to be complete. So, go ahead and add these user stories to the appropriate features.


Does the story belong into the feature?
Is it necessary for the feature?

Stories get grouped into features to make it easier to talk about groups of stories. Features get estimated, they get priorized, they get scheduled during "high level" sessions with stakeholders, who would not be expected to understand every individual story. The stakeholders decide "should we implement feature A or feature B? Time and manpower are limited."

So if you discover during the implementation of a feature that you have forgotten a necessary story to make that feature work, you have two options: add the necessary story to the feature, or stop work on the feature and go back to the stakeholders with a refined estimate of effort.

In this case, expanding the existing feature is a natural part of the development.

If you understand during the implementation of a feature that the product might be improved by doing even more than originally planned, you write that up as a new feature and go through the planning process again. The stakeholders might like the improved feature, or they might want something else more urgently. Note that you should not create "a new feature," you should create as many new features as there are distinct groups of stories.

In this case, expanding the existing feature is a way to circumvent the decision processes which got the work on the feature authorized to start with.


A few other idle thoughts ...

When anything changes the course of the project or its requirements, capture it. If the story changes, capture the new story, but don't discard the old one. Maintain a "running log," or diary, in which every discussion, decision, and approved change is meticulously recorded.

Put your design and planning documents under version control. (git, etc.)

Since users do "know it [only ...] when they see it, I have found it extremely useful to construct HTML prototypes – not just "wire frames." Present it to the user as: "this is what it's going to look like ... now I just have to go and make it move." The prototype is literally static HTML, with simple hyperlinks (maybe). But the user can *see it," on their own browser screen, and they can pretend to interact with it. (People turn out to be really good at "pretending!" Strive to harness the power of "brainstorming.")

And, when they're finally approved, the prototypes can become the literal basis for the templates that you'll eventually use to construct the pages.


What you are describing is classic feature creep.

What you need to institute is a Change Process.

Change Requests are submitted to a queue and then reviewed - much the same way the backlog is reviewed.

The team decides on the value and cost (in time and/or money) of the feedback and then decides if this Change Request will be included in the current release or in a future release.

Hint: very few change requests should be in the coming release. Requests that affect functionality in a serious way are good candidates - but then they are not automaticaly included. Others - if deemed important enough - can be slated for a Post Release Update that will be planned for as soon as possible after the current release.

The Change Request queue can then be updated with the relevant information, such as if it was accepted and which release it's slated for, so that the change requester knows what to expect.

The alternative, as you hinted to, is to be forever chasing a moving target.

Using this technique you can release as planned. This is good for team morale and for your reputation. (Nobody will remember that you were late because "they" demanded changes.)

Then the customer can decide to not use it for a week or 2 until the updated release. That's perfectly acceptable and sensible. When you have the chosen changes ready you can release again.

If you prefer, you can call the initial release the pre-release.

In summary: don't let feature creep turn your release into a moving target. Release on-time and then again, soon after, with the changes. Only bugs that break functionality are not included in the above.

  • 1
    Danny, you are proposing that "change request" should be something different from an item on a backlog? I think most people understand that every item on a backlog is potentially a change and that they have have one common prioritisation process for all. If you release continuously / regularly enough then there's no such thing as feature creep, there is just a relative priority for backlog items. – nvogel Feb 28 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.