We have a product which is in active development.

For live issue tracking purposes we are creating a monthly milestone. If we will not be able to complete that milestone in the current month, then we will move all open tickets to the next month's milestone.

Should we be doing this or is there a better alternate?

put on hold as unclear what you're asking by Todd A. Jacobs yesterday

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    What is the purpose or value of these milestones? – Erik Aug 1 '18 at 17:39
  • To track the live issues.. – Alok Aug 1 '18 at 17:40
  • "Milestone" and "deadline" aren't synonyms. What is the expected value to the business of tracking your open tickets in this way? – Todd A. Jacobs Aug 2 '18 at 4:45
  • Value is to finish the live issues and track and separate them on monthly basis.. – Alok Aug 2 '18 at 4:49
  • 1
    @Alok That's a circular argument. So, the value of doing it is just that you're doing it? You probably need to rethink this. How do you plan to measure success? What will happen if the team isn't successful? – Todd A. Jacobs Aug 2 '18 at 8:03

What is milestone

I think, you are talking about an iterative process, where in the end of each iteration you release your product with newly implemented features. And you call the releases as milestones.

Why guys are little bit confused is because it's better to think of milestones as about dates, when you achieve some specific business goals, not just releasing new features (though, if there are some business goals achieved by the released features -- yes, this is milestone too). For example: "Product is integrated with Salesforce" or "UAT is starting" or "Traffic increased 30%".

Should we move tasks?

Back to your question: yes, you can move unfinished tasks to the next iteration. But it depends. And following approach is my favorite.

  1. For every iteration all features should be split on two groups: Must-priority -- for must-have features and Should-priority -- for features that can be postponed to the next release in case of problems with must-have features.
  2. Split features as small as possible in order to be able to release partial valuable functionality, if you are not able to complete everything.
  3. If you can't release whole feature -- release part of it at least. But still, release it being simplified, but complete feature -- don't release only UI for example.

BTW, you are talking about "tasks". But it's much better to talk in terms of features or User Stories. Tasks -- are technical tasks, and they usually can not be split or prioritized in business terms, i.e. they don't make sense for end-user. Features or Stories, instead, can be usually prioritized, moved and split on parts which still make sense for end-user. I.e. they are much more useful from Product Management point of view.


Disclaimer: will do a lot of assumptions here :)

Assumption #1 - milestones are the term used to represent a group of open "defects" / "technical debts" being planned to be addressed during a given period (a month, it seems)

Assumption #2 - you are not considering day to day activities as part of these milestones

Assumption #3 - the purpose of the milestone is to give visibility to senior management on the known issues that have been addressed during the period

Assumption #4 - there's no reserved capacity to exclusively address these items, i.e the capacity is shared with day to day activities

Based on the above assumptions, then you need to have one flexibility in one of your dimensions... scope or time.

Flexible scope: You stick to the monthly delivery pack with a prioritised set of items. You can use something like a prioritised Kanban and the team will address as much items as possible. At the end of the period, a package of the completed items will be generated, delivered to production and reported to the senior management. Remaining items, lower in priority, will automatically be addressed during next period.

Flexible period: You commit to a specific scope, and your team will work on it on best endeavours. Once the committed scope is completed, a package of the committed items will be generated, delivered to production and reported to the senior management.

I'm managing a services project for an year or so, and we do a mixture of both - for the items that can be planned, we forecast roughly 50% of the capacity and work on iterations with specific goals. The other 50% is forecasted for unplanned and day to day services work. Needless to say, there are periods where the % heavily swings towards both planned and unplanned services - but there's an "intention of deliverables" per iteration (i.e. we use fixed period approach).


If the month is an arbitrary reporting/visibility bucket in which to show "what are we working on now", then this approach seems harmless, assuming you are applying project management in other ways.

If the monthly milestone is supposed to constitute a development schedule, and you are not managing the scope and schedule of the project in other ways, then this is a terrible idea, because there's nothing to prevent a increasingly large pileup of work as time goes on.

If the monthly milestone is supposed to constitute a development schedule, and you are consistently only leaking a little bit from month to month, then it's probably not too bad.... but in order to know whether you are only leaking a little bit from month to month, you'd need at least one other metric to track that. (for example, the number or fraction of monthly milestone tickets still incomplete at the end of the month, and plot the data historically.) Then if you see early signs of a pileup, you'll know the project is heading into trouble & needs more aggressive PM.

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