3 ms·

My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions thr

My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined. My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often. But alas, everyone has a different philosophy. :)

jacques_chester 7y ago
Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out. My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.
- dfischer 7y ago
  To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though. Definitely agree with smallest possible units of value (that also varies per a person).
  - jacques_chester 7y ago
    Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.
    - dfischer 7y ago
      Perfect! Music to my ears.

jacques_chester 7y ago

Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out. My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.

dfischer 7y ago
To clarify my definition: Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code. This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on). It seems you agree with my view of a minimum of 1 week before it can change. I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though. Definitely agree with smallest possible units of value (that also varies per a person).
- jacques_chester 7y ago
  Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.
  - dfischer 7y ago
    Perfect! Music to my ears.