Generally I'd I'd say between 2 and 4 weeks. How long can the business leave the team alone to get on with what they've planned (the "no interruptions"rule) is one constraint. The other is how frequently do we need to update the release plan - we only really get feedback on velocity at sprint boundaries.
I've been working with a team recently where establishing a constant velocity has been very difficult. They are basically dealing with a large backlog of defects from previous iterations where they weren't using an agile process. Until this backlog is cleared it's largely academic how long the sprint is - they still get interrupted with a significant number of urgent defect fix tasks every week. Perhaps going to a weekly sprint, at least until this backlog is effectively cleared would help. That way the defects being worked on in that week would be known, with analysis only being done on new defect reports during the week. The sprint planning for the following week can then re-prioritize the work for the following week. This is an example of where the sprint needs to be short in order to handle rapidly changing priorities. However it also demonstrates the difficulty of trying to apply an agile process when a clear quality baseline has not yet been established.
In other circumstances I favour a longer sprint rather than a short one - at least 3 weeks. It gives the team a chance to establish it rhythm of delivering backlog items without the overheads of sprint planning and retrospectives interrupting.
The Improving Projects blog from Huge IO (UK & Ireland) is primarily about products, organisations and projects... and how to improve them. As well as musings on agile processes, software engineering in general, and methods like Kanban and Scrum, there's advice here too for users of process planning, execution and improvement tools - and the metrics they can provide. https://uk.huge.io
Subscribe to:
Post Comments (Atom)
Breakout sessions that ensure everyone in the meeting meets everyone else
Lockdown finds us doing more and more in online meetings, whether it's business, training, parties or families. It also finds us spendin...
-
Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many su...
-
Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - ...
-
Understanding Cost of Delay (Part 2): Delay Cost and Urgency Profiles In part one of this series of blogs on Understanding Cost of Dela...
No comments:
Post a Comment