search back preload
The Scrum Framework . Continuation
PDF
Print
E-mail
Written by Daniel Pedemonte   
Wednesday, 23 January 2013 14:54

An outcome-oriented Coaching Process that you can easily apply to any situation, Part TWO

Fotolia 30040609_S

 

Hello everyone. Continuing our yesterday’s conversation about Scrum Framework, today we’re going to keep talking about the process that started with a Product Backlog created by the Product Owner to list and prioritize the steps that would eventually lead to the realization of the original idea.

Let’s review today the basic steps that follow, starting with…


3. Sprint Planning

This is a process in which the Product Owner, the Agile Coach and the Team Members decide on which items they are going to work on as a start and they define a time frame for that work at hand.

. Time frames:
A Sprint is a measure of time. It can go from 2 to 4 weeks, but no longer than that. Why is that? Looking ahead to a period of more than 4 weeks, people start to get “saggy around the edges of labor”, starting to get fooled under the illusion that there will be enough time to finish… start with a little procrastination and usually falls into the Niagara Syndrome, where you let yourself float down the stream until there is too late to turn around and start padding.
4 weeks is a time we can handle. Beyond that 30 days perspective it all gets a little blurry.

. Sprint Backlog:
Once you know your time frame and who’s on your team (meaning their knowledge and expertise), you can determine how much of the Product Backlog you can handle at that time.

This sprint action capacity can be easily calculated without the use of mathematics or fancy schedules. People have the natural capacity to feel instinctively when they are taking enough or too much for a certain workload and timeframe.

. Negotiating the List:
The Product Owner starts reviewing the highest priorities in the Backlog list with the Team and then starts to add items to the Sprint Backlog.
The PO bases his choices upon the practical relevance and urgency of the items.
The Team base their acceptance upon technical criteria and correlative convenience; for instance: the PO proposes item number 4 on the list, but certain technical aspects pairs this item with number 7, so they propose it back to the PO, and so they continue this negotiation until they reach a spot where the Team know their production capacity is full -simply stated, that’s all they can commit to do in that period of time.

Once the Sprint Backlog is defined, a “noise shield” is laid on the team members to protect them and their work from all kinds of interference from all the people involved in the project that want to have a say on what should or shouldn’t be done, and how and when. They might be (and no offense intended) team managers, service managers, stake holders, legal advisors, users, etc.
The PO takes all their advices, adds them to the Product Backlog and prioritizes them, but the agreed Sprint Backlog remains undisturbed (anyway, whatever they are itchy for, they can wait, after all it’d never be longer than 4 weeks right?)

 

We'll continue reviewing this process tomorrow, starting with the Scrum work itself and the steps the Team Members will have to take in order to achieve all the items they committed to do.

See you tomorrow, 

avatar-mini

Dan C. Pedemonte
Agile Coach . Human Potential Strategist 

 


 


Last Updated on Wednesday, 23 January 2013 17:13
 

RSS-header

RSS-bottom