Project Management

Please login or join to subscribe to this thread

In Agile, do duration of iterations fixed constantly?

linkedin twitter facebook   Agile  
avatar
Doan Van Duc Asaka, 11, Japan

Hi everyone, I with my co-worker are debating about the definition of duration of iterations in an Agile project. I need the exact answer as PMI's theory.



My opinion: If the duration of iterations are fixed at project charter (example 4 weeks), then all of another iterations during implementing project should be 4 weeks. And this duration is time-box (shouldn't be changed)



My co-worker's opinition: The duration of iterations may be changed between iterations as long as they are time-box. Example the duration of the fifth iteration is 4 weeks, but the sixth iteration's is 2 weeks.



Thanks in advanced
Sort By:
avatar
Tony Sadowski Project Manager| Pomeroy Technologies Mooresville, Nc, United States
My opinion, in an Agile environment you have to adapt and change as the project/product develops. So there would not be firm standard iterations.
avatar
Keith Novak Tukwila, Wa, United States
I agree with Tony. I would not want to box my team into a time estimated at the very beginning of the project before the team is even fully staffed.

If the team has not worked closely together before, you are not fully aware of their capabilities or how well the people work together. It might take a few iterations to find the right speed.

The team may change over time. Bringing in an expert could slow things down until they better understand the project and then speed up once they are fully engaged.

Some iterations may be bigger than others. Adding features or fixing bugs, the PM can control the volume of change in an iteration and may impact a subset of your full product team. Updating the data standards such as an XML change could be a much broader impact both to design and testing.
...
1 reply by Tony Sadowski
Feb 08, 2024 10:33 AM
Tony Sadowski
...
Thank you Keith for elaborating more on the topic...agile deployments are always evolving and changing with the more the product/project grows into of itself.
avatar
Tony Sadowski Project Manager| Pomeroy Technologies Mooresville, Nc, United States
Feb 08, 2024 10:17 AM
Replying to Keith Novak
...
I agree with Tony. I would not want to box my team into a time estimated at the very beginning of the project before the team is even fully staffed.

If the team has not worked closely together before, you are not fully aware of their capabilities or how well the people work together. It might take a few iterations to find the right speed.

The team may change over time. Bringing in an expert could slow things down until they better understand the project and then speed up once they are fully engaged.

Some iterations may be bigger than others. Adding features or fixing bugs, the PM can control the volume of change in an iteration and may impact a subset of your full product team. Updating the data standards such as an XML change could be a much broader impact both to design and testing.
Thank you Keith for elaborating more on the topic...agile deployments are always evolving and changing with the more the product/project grows into of itself.
avatar
Kiron Bondale Retired | Mentor| Retired Welland, Ontario, Canada
Tony -

In general, I'd say that for a given release within a project, if you wish to use vanity metrics like velocity to do forecasting, then you'd want fixed duration iterations. This also creates consistency with stakeholders for the events they would be attending (e.g. sprint reviews).

However, sprints are (rather poor) training wheels on the road to become more agile. As such, if a team finds mid-stream that they can dispense with them in favor of a continuous flow approach, that is fine so long as it is a team decision and stakeholders are appropriately informed.

Kiron
avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
First of all, Agile is not about using iterations. You can use Agile with waterfall, V, iterative, Incremental, iterative-incremental, and more life cycles. But if you are using iterative-incremental then is because you commit to deliver something after each increment. The key thing in this type of schemas is cadence because it address predictability then you can create solution roadmaps and that sense then you can calm the nerves of stakeholders. With that said, the recommendation is to have fixed iterations and the amount of iterations for each increment, in some places, are adjusted to defined organizations quoters. But if you are using iterations just without increments committed into it then, while is not recommendable, the iterations durations can be adjusted to the needs after initial estimation. You are creating solutions for business problem then market times and opportunities windows have to be taken into account when you define cadence and iterations.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Man is the only animal that blushes. Or needs to."

- Mark Twain

ADVERTISEMENT

Sponsors







Newsletters

Jun 17: 7 Ways to Show Business Acumen Every Day
Jun 3: The Career Problem Facing New PMs
May 20: Your PM Career as a Project Life Cycle

See all newsletters