On Thu, May 19, 2011 at 7:29 AM, Ilias Biris ilias.biris@linaro.org wrote:
On 19/05/11 14:19, Peter Maydell wrote:
Sure. As I understand the idea of an agile product backlog, though, you don't necessarily do full investigation and planning on every item in it (in the way that at the moment we do full down-to-the-work-item blueprints for everything at the start of the six months); instead you can just do broad back-of-envelope estimates and prioritisations and only need to do more detailed planning as things bubble up to the top of the backlog.
The product backlog defines the release, which should stay at 6m in my opinion. With agile, just because you have a demoable, releasable chunk of work done at the end of a sprint, doesn't mean that you actually have to release it. It is just a demo for stakeholders to make sure everything is on track. More interaction with the stakeholders is key to this working. Then you don't work heads-down for 6m on something just to find that out that the target has moved.
-- PMM
The way I see this: It means the backlog items targeted for the next sprint/month get their work items defined in detail, whereas the remaining backlog items not yet in the radar, can get only a rough breakdown to work items. For the not detailed planned blueprints one should consider flagging any risks which may impede the work early on.
Ideally higher priority items are taken earlier in the cycle, since the cost of their delay is higher.
What comes to estimating, it ought to happen regularly - for example before the beginning of a sprint/month. Use ideal/uninterrupted hours/days for your estimates.
Yes, plan often - it is less of a disruption and takes less time if it happens often. Every sprint starts by re-prioritizing the backlog.
Cheers,
-- Ilias Biris, Aallonkohina 2D 19, 02320 Espoo, Finland Tel: +358 50 4839608 (mobile) Email: ilias dot biris at linaro dot org Skype: ilias_biris
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev