I was remembering my visit to Paris in 2012 after hearing the extremely sad news in the mean while i was searching for a current issue i was facing in my Release plan. Mike Cohen news letter give me an idea which is mentioned as:
Let’s suppose we’re planning a holiday somewhere awesome. Let’s make it Paris. I said awesome, didn’t I?
You don’t want to plan every waking moment of the trip. But if you only have a week in Paris, you probably want some sort of plan. You might plan on a couple of days in museums, a day trip out to Versailles, a day strolling the Champs-Élysées, and so on.
Unless you are far more anal than I am, though, you probably would not plan 10:15 a.m. to 3:30 p.m. at Musée d'Orsay, coffee until 4:18 p.m., and so on. You would leave some slack in your schedule. You do this because you want to leave time for things you’ll discover once you’re in Paris.
Similarly, we need to leave slack in our agile team’s release plans for things that will be discovered during the project.
I see product owners who look at a team’s velocity, multiply that by the number of remaining sprints, determine which product backlog items will be delivered, and then guarantee those items will be delivered. Don’t do this. Although that calculation can roughly estimate the amount of functionality that can be delivered, the product owner should not promise specifically those items.
Stakeholders and the product owner will identify new features as the project progresses. Every project of any significant size has what are known as emergent requirements. An emergent requirement is a feature that stakeholders could not have thought of in advance.
So it’s not just a feature that stakeholders failed to think of by rushing or being lazy. It’s a feature they could not think of until they saw a partial implementation of the system and went hands-on with it.
Product owners need to acknowledge these exist and will be discovered as a project progresses--just like you’ll find great cafes down hidden side streets in Paris.
And by doing so, we can succeed with agile.
Let’s suppose we’re planning a holiday somewhere awesome. Let’s make it Paris. I said awesome, didn’t I?
You don’t want to plan every waking moment of the trip. But if you only have a week in Paris, you probably want some sort of plan. You might plan on a couple of days in museums, a day trip out to Versailles, a day strolling the Champs-Élysées, and so on.
Unless you are far more anal than I am, though, you probably would not plan 10:15 a.m. to 3:30 p.m. at Musée d'Orsay, coffee until 4:18 p.m., and so on. You would leave some slack in your schedule. You do this because you want to leave time for things you’ll discover once you’re in Paris.
Similarly, we need to leave slack in our agile team’s release plans for things that will be discovered during the project.
I see product owners who look at a team’s velocity, multiply that by the number of remaining sprints, determine which product backlog items will be delivered, and then guarantee those items will be delivered. Don’t do this. Although that calculation can roughly estimate the amount of functionality that can be delivered, the product owner should not promise specifically those items.
Stakeholders and the product owner will identify new features as the project progresses. Every project of any significant size has what are known as emergent requirements. An emergent requirement is a feature that stakeholders could not have thought of in advance.
So it’s not just a feature that stakeholders failed to think of by rushing or being lazy. It’s a feature they could not think of until they saw a partial implementation of the system and went hands-on with it.
Product owners need to acknowledge these exist and will be discovered as a project progresses--just like you’ll find great cafes down hidden side streets in Paris.
And by doing so, we can succeed with agile.
No comments:
Post a Comment