3 ms·
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 c
by 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 agoTo 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 agoYes, 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 agoPerfect! Music to my ears.