Skip to main content
replaced http://pm.stackexchange.com/ with https://pm.stackexchange.com/
Source Link

TL;DR: On the top of the product backlog.

Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.

You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks later will consume much more time then doing it now, because everything is still fresh in memory.

Handling defects

I suggest you implement a zero-defect policy, see this answer for more details: http://pm.stackexchange.com/a/19805/8528https://pm.stackexchange.com/a/19805/8528

Promote product readiness:

There is a saying in XP that production starts on day one of the project. From the first day you write a line of code, you treat the project as if it were in production, and after that, you are merely making changes to a live system.

It’s a profound difference in how you view your code. Instead of viewing production and deployment as some event way off in the distant future, you imagine you and your team are in production today and start behaving accordingly.

Doing this has the following advantages:

  • Team respects the code base - leading to higher quality.
  • It’s easier to make changes - as a result of well refactored code.
  • Pride of ownership goes up - because team is doing quality work.
  • You can release at any moment - which is the only time we add value.

enter image description here

TL;DR: On the top of the product backlog.

Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.

You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks later will consume much more time then doing it now, because everything is still fresh in memory.

Handling defects

I suggest you implement a zero-defect policy, see this answer for more details: http://pm.stackexchange.com/a/19805/8528

Promote product readiness:

There is a saying in XP that production starts on day one of the project. From the first day you write a line of code, you treat the project as if it were in production, and after that, you are merely making changes to a live system.

It’s a profound difference in how you view your code. Instead of viewing production and deployment as some event way off in the distant future, you imagine you and your team are in production today and start behaving accordingly.

Doing this has the following advantages:

  • Team respects the code base - leading to higher quality.
  • It’s easier to make changes - as a result of well refactored code.
  • Pride of ownership goes up - because team is doing quality work.
  • You can release at any moment - which is the only time we add value.

enter image description here

TL;DR: On the top of the product backlog.

Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.

You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks later will consume much more time then doing it now, because everything is still fresh in memory.

Handling defects

I suggest you implement a zero-defect policy, see this answer for more details: https://pm.stackexchange.com/a/19805/8528

Promote product readiness:

There is a saying in XP that production starts on day one of the project. From the first day you write a line of code, you treat the project as if it were in production, and after that, you are merely making changes to a live system.

It’s a profound difference in how you view your code. Instead of viewing production and deployment as some event way off in the distant future, you imagine you and your team are in production today and start behaving accordingly.

Doing this has the following advantages:

  • Team respects the code base - leading to higher quality.
  • It’s easier to make changes - as a result of well refactored code.
  • Pride of ownership goes up - because team is doing quality work.
  • You can release at any moment - which is the only time we add value.

enter image description here

Source Link

TL;DR: On the top of the product backlog.

Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.

You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks later will consume much more time then doing it now, because everything is still fresh in memory.

Handling defects

I suggest you implement a zero-defect policy, see this answer for more details: http://pm.stackexchange.com/a/19805/8528

Promote product readiness:

There is a saying in XP that production starts on day one of the project. From the first day you write a line of code, you treat the project as if it were in production, and after that, you are merely making changes to a live system.

It’s a profound difference in how you view your code. Instead of viewing production and deployment as some event way off in the distant future, you imagine you and your team are in production today and start behaving accordingly.

Doing this has the following advantages:

  • Team respects the code base - leading to higher quality.
  • It’s easier to make changes - as a result of well refactored code.
  • Pride of ownership goes up - because team is doing quality work.
  • You can release at any moment - which is the only time we add value.

enter image description here