So Im a new Scrum Master and I'm starting my new team
How do I pick the length of the Sprint?
As Mary Poppendieck says, “the more often you do something hard, the easier it will become”. The sprint length is ultimately a team decision. There are some guidelines, however.
First, the entire release should have a constant sprint length. Before you specify a particular length, you should do some simple constraint determinations:
What do we use for initial velocity or how do we decide how much we can take on for the first sprint?
The velocity for the first sprint is always the hardest, mostly because the team has not typically worked together before and definitely, they have not done this (what ever this is) before. So, that doesn’t answer the question does it? Well, my experience is that teams that have not worked together or have not yet jelled into an agile organization (i.e., the team still has functional separations), runs at about a 20% velocity factor. Teams that have worked together and have worked on an agile project before tend closer to 45%. I have never seen a team cross the 50% boundary, nor would I want one to.
As an aside, lets take a typical case: given a three week sprint with 4 hours of planning meeting, 3 hours of Review meeting and 1 of retrospective added to a 15 minute standup every day. Anticipate 1 sick or vacation day (on average each sprint) and couple that with a half hour 1-1 with you supervisor each week. Additionally, expect to be involved with some touch point meetings summing to an hour each week with the product owner. We are immediately at 80% available time even before we deal with interviews, email, phone calls, collaboration and other necessary activities. This type of communications can easily chew up another 25% of your time (roughly 2 hours a day). Now you begin to examine the inefficiencies the team develops due to its communication and it is real easy to understand how a velocity of 20-30% can be anticipated initially.
I know what they tell me they want done in this release, but how do I do a Release Plan the team can work from?
The term release plan in our organization is a much overloaded term. Principally, we use it to mean the macro plan necessary to take a marketing and sales objective and transmogrify it into a set of software that can be evolved into an RTM candidate which can, in turn, be released on the website or as a CD/DVD. Now, this plan must include the non-developmental tasks, such as those associated with taking the release candidate and moving it through manufacturing, but in general, we are referring to the processes of gathering requirements, translating them into stories, developing the stories (and validating them of course), and finally integrating the system with all necessary external interfaces.
The key behind agile is knowing the appropriate perspective to use at each stage of your development. We must have a general perspective for all the work that should be done, though a much more specific idea for the work that will be done first. The approach I recommend is to work with the product owner to prioritize the requirements into three categories: Must, Need, Want. We WAG estimates for everything (on all elements of the development team – Development, QA & Test, and Tech Pubs).
Developing the release plan is as much of an art form as any of the other development tasks. Here, what we need to do is interpret the subtle priority differences between the Must-Haves and the Need-to-Have or the Want-to-Haves. Additionally, we must be able to get the team WAG the levels of effort necessary at least to the 50th percentile point – the point at which the team generally believes that there is only a 50% chance that their estimates might be wrong.
I vaguely remember the chartering process. I am starting a new release, what do I do?
Charter is an old term that we have chosen to revitalize. The dictionary definition connotes the process by which a sovereign power grants privilege. The term used to be used to describe the enablement of a major (and noteworthy) enterprise: the chartering of a boat to discover the northwest passage, the chartering of the new state of West Virginia, the chartering of a new branch of an organization focused on helping its community (e.g. the Rotary). Our releases are noteworthy. They are major. Senior management here is more realistic than to consider themselves sovereign, except metaphorically, but certainly within that metaphor, any development team needs to be granted with the authority to spend the company’s coin on the pursuit and execution of new work.
Chartering is the process by which we ask for and receive that authority. It is driven by our Product Owners supported by our Core Team.
What is the Chartering process?
The first step in the chartering process is to take the concept for the release and flesh it out. To do this, the core team defines a statement of purpose and establishes a business case and then works through critical aspects of the execution to determine if they can convince themselves of a means by which the value proposition can be achieved. This exercise is detailed in the How do we charter our Release? entry below.
The second step takes place once the Charter has been granted. At that point, we charter the team that will execute the release. The objective of this step is to ensure that everyone one the team has a complete understanding of what is expected of them for the release, both by role and by action. This activity gives individual team members the opportunity to question estimates or approaches and re-examine assumptions. The objective of this step is to gain consensual acceptance of the commitment for the release.
The third step takes place prior to every sprint planning session. This step is an abbreviated Team Chartering activity and asks a single question of the team: Do we still accept the charter? We use this as an opportunity to re-validate assumptions and business need, as well as to undertake midcourse corrections if necessary. The slogan for these sessions should be no surprise, good or bad.
How do we charter our Release?
This is the primary chartering activity and the most significant. It is to work with the product owner to fill out the Chartering Deck so as to have an artifact through which to gain authority to undertake the release. Initially, it is an exercise for the core team to ensure they understand the drivers and the value proposition to the company for undertaking this release. Ultimately, once complete, it is a vehicle upon which the charter can be requested from Executive Management.
The nine components of the Release Chartering Process are to:
Team chartering is led by the Scrum Master and the Product Owner jointly. The objective is to establish roles and responsibility for the team members and both solicit and achieve their buy-in. To reduce the tendency for this to become a lecture, it is often useful to start with roles, responsibilities, and introductions. Even though everyone probably knows each other, start the chartering process with an opportunity for each functional group, by function, to introduce themselves. Specifically, you should ask the individuals to state what they would like to get out of their work on this Release – I would like to become more aware of our database design, I would like to be able to proctor the field trial, I would like to better understand what Quality Assurance really is, I would like to write an article on our process, etc.. Having everyone understanding where individuals want to go will help the team achieve their personal goals.
Next, the Product Owner should present the chartering deck that had been presented to Executive Management while seeking the charter. During this presentation, the order should be slightly different, so that the presentation concludes through the Scope, Estimates, Technical Vision and then the Assumptions. This is so that the team can have this pertinent data fresh in their minds while they listen to the assumptions. Once the material has been presented, the floor should be thrown open with the single question: Given these assumptions and this approach, can you accept these estimates within our anticipated (and stated) statistical variation? If the team can not they must, as a group, understand why they do not feel able to accept the estimates (the book of work), and then review and revise the plan until they are able to accept a similar charter. Before work can begin, this modified charter will need to be represented to the Executive Team to reset expectations. If not concurrence can be made, the Product Owner must go back to the Executive Team and let them know that the Team will not accept the undertaking.
What are the chartering steps prior to each Sprint?
Once the Release has started, the team must revisit the Charter prior to every sprint. The purpose of this is to revisit the assumptions that were made initially and to determine if any have changed. If they are no longer valid, adjustments may need to be made to the plan. Additionally, it is useful to review the risks and their mitigation based upon experience and new information.
Operationally, I recommend opening each Sprint Planning meeting with a representation of the Scope and Assumption slides from the Charter, as well as a Release BurnUp chart representing how our actual velocity projects out against our current accepted scope (based upon current estimates). If things have changed with scope or assumptions, we will need to understand how that reflects back through our productivity trends as well as the attainment of our Release goals. Actual content of the sprint may change based upon these realizations.
We have just finished our first sprint. What happens if we didn’t finish everything?
Unfinished work is considered Hangover. This can include anything from work that proved to be more complex than anticipated and hence too longer to complete, to work that remained unverified due to illness in the QA team, to something that the Team felt they completed but the Product Owner was not able to accept without modification. All stories that are not done are put to the top of the list of stories for the next sprint. Prior to committing them to the sprint backlog for the next sprint; however, the product owner has the opportunity to examine them, their value and risk at this point in the release, and move them out of the sprint backlog to the product backlog for later completion. Though this does not often happen, where it does come into play frequently is when there is going to be an interim sub-release and stories that don’t actually make it into the field then may have substantially lower priority than some others that are coming up later.
How do I calculate velocity?
Velocity is a measure of team productivity against the release/sprint goals. It should not be used to measure individual productivity because the statistical variation of a single data point does not produce an accurate representation. Additionally, it is important to remember that when we say productivity against goals, we do not mean to insinuate that people are not doing work if their velocity is low, we just mean that their progress against the project goals is slower, most likely because they are doing other things for the company, not directly translatable to the project goals.
Therefore, Velocity is the sum of the units (ideal days or hours) estimated for all the tasks undertaken and completed during the sprint divided by the total number of units available to the team to produce deliverable work. Velocity is a unit-less percentage. Here is an example:
A team of 7 using 3 week sprints took on 8 stories whose rolled up tasks summed to 300 ideal hours. Unfortunately one of the developers was sick for a couple of days and the team was not able to complete the story which included the tasks he was working on. The 7 stories that were completed and marked done by the product owner represented only 230 ideal hours. Though the remaining story is only perhaps 20 hours shy of completion (development and verification), none of its work can be taken credit for, as it can not be incorporated into a working baseline. The team of 7 had 840 available hours to work over the sprint. This produced an effective velocity of 230/840 or 27.3%.
Using this as a reference to yesterday’s weather, the team would be recommended to take on between 230 and 300 ideal hours, based upon the groups of stories being selected by the product owner. You would not push down to 230 immediately, as this sprint may have been struck by bad luck (wrong person working on the wrong story getting sick at the wrong time), but the trend must be looked at and if insufficient margin has been included to take into consideration historical sick time, the objectives should be ratcheted back a notch.
As Mary Poppendieck says, “the more often you do something hard, the easier it will become”. The sprint length is ultimately a team decision. There are some guidelines, however.
First, the entire release should have a constant sprint length. Before you specify a particular length, you should do some simple constraint determinations:
- Look forward from where you are starting and inquire as to who might be taking lengthy vacations. You want to minimize the number of iterations where the Scrum Master, the Customer, or the Team leads are not available for a sprint review or planning session.
- Look at normal holiday periods (particularly if this release spans the festive TDay/Xmas season in the US or the New Years/Xmas season in Russia, etc.)
- Look at the type of stories that will be undertaken in this release – are the complex or simple (or mixed)? Can perceivable value be derived in 1 week, 2 weeks, 3 or more?
- Think about waves of functionality, particularly if the product owner is going to want to do an early field test. How long will it take to create something fieldable?
What do we use for initial velocity or how do we decide how much we can take on for the first sprint?
The velocity for the first sprint is always the hardest, mostly because the team has not typically worked together before and definitely, they have not done this (what ever this is) before. So, that doesn’t answer the question does it? Well, my experience is that teams that have not worked together or have not yet jelled into an agile organization (i.e., the team still has functional separations), runs at about a 20% velocity factor. Teams that have worked together and have worked on an agile project before tend closer to 45%. I have never seen a team cross the 50% boundary, nor would I want one to.
As an aside, lets take a typical case: given a three week sprint with 4 hours of planning meeting, 3 hours of Review meeting and 1 of retrospective added to a 15 minute standup every day. Anticipate 1 sick or vacation day (on average each sprint) and couple that with a half hour 1-1 with you supervisor each week. Additionally, expect to be involved with some touch point meetings summing to an hour each week with the product owner. We are immediately at 80% available time even before we deal with interviews, email, phone calls, collaboration and other necessary activities. This type of communications can easily chew up another 25% of your time (roughly 2 hours a day). Now you begin to examine the inefficiencies the team develops due to its communication and it is real easy to understand how a velocity of 20-30% can be anticipated initially.
I know what they tell me they want done in this release, but how do I do a Release Plan the team can work from?
The term release plan in our organization is a much overloaded term. Principally, we use it to mean the macro plan necessary to take a marketing and sales objective and transmogrify it into a set of software that can be evolved into an RTM candidate which can, in turn, be released on the website or as a CD/DVD. Now, this plan must include the non-developmental tasks, such as those associated with taking the release candidate and moving it through manufacturing, but in general, we are referring to the processes of gathering requirements, translating them into stories, developing the stories (and validating them of course), and finally integrating the system with all necessary external interfaces.
The key behind agile is knowing the appropriate perspective to use at each stage of your development. We must have a general perspective for all the work that should be done, though a much more specific idea for the work that will be done first. The approach I recommend is to work with the product owner to prioritize the requirements into three categories: Must, Need, Want. We WAG estimates for everything (on all elements of the development team – Development, QA & Test, and Tech Pubs).
Developing the release plan is as much of an art form as any of the other development tasks. Here, what we need to do is interpret the subtle priority differences between the Must-Haves and the Need-to-Have or the Want-to-Haves. Additionally, we must be able to get the team WAG the levels of effort necessary at least to the 50th percentile point – the point at which the team generally believes that there is only a 50% chance that their estimates might be wrong.
I vaguely remember the chartering process. I am starting a new release, what do I do?
Charter is an old term that we have chosen to revitalize. The dictionary definition connotes the process by which a sovereign power grants privilege. The term used to be used to describe the enablement of a major (and noteworthy) enterprise: the chartering of a boat to discover the northwest passage, the chartering of the new state of West Virginia, the chartering of a new branch of an organization focused on helping its community (e.g. the Rotary). Our releases are noteworthy. They are major. Senior management here is more realistic than to consider themselves sovereign, except metaphorically, but certainly within that metaphor, any development team needs to be granted with the authority to spend the company’s coin on the pursuit and execution of new work.
Chartering is the process by which we ask for and receive that authority. It is driven by our Product Owners supported by our Core Team.
What is the Chartering process?
The first step in the chartering process is to take the concept for the release and flesh it out. To do this, the core team defines a statement of purpose and establishes a business case and then works through critical aspects of the execution to determine if they can convince themselves of a means by which the value proposition can be achieved. This exercise is detailed in the How do we charter our Release? entry below.
The second step takes place once the Charter has been granted. At that point, we charter the team that will execute the release. The objective of this step is to ensure that everyone one the team has a complete understanding of what is expected of them for the release, both by role and by action. This activity gives individual team members the opportunity to question estimates or approaches and re-examine assumptions. The objective of this step is to gain consensual acceptance of the commitment for the release.
The third step takes place prior to every sprint planning session. This step is an abbreviated Team Chartering activity and asks a single question of the team: Do we still accept the charter? We use this as an opportunity to re-validate assumptions and business need, as well as to undertake midcourse corrections if necessary. The slogan for these sessions should be no surprise, good or bad.
How do we charter our Release?
This is the primary chartering activity and the most significant. It is to work with the product owner to fill out the Chartering Deck so as to have an artifact through which to gain authority to undertake the release. Initially, it is an exercise for the core team to ensure they understand the drivers and the value proposition to the company for undertaking this release. Ultimately, once complete, it is a vehicle upon which the charter can be requested from Executive Management.
The nine components of the Release Chartering Process are to:
- Define the Release – state the purpose and business case (value proposition)
- Define Goals and Objectives – specifically how they relate to the component groups undertaking the release
- Describe the Business Vision – this will be what Product Marketing hands off to Sales to sell this new release to the field
- Identify the Scope – what we will develop, what we will not, and what areas are still undetermined.
- Identify Assumptions – these are what establishes priorities for the release
- Define the Technical Vision – illustrate the architectural vision and usage models for changes undertaken in this release
- Identify High Level Risks – create a risk/reward diagram
- Project Staffing – identify who and where the work will be done
- Project Estimates – Craft a release plan based upon high level estimates and basic concepts of staff loading. With Product Marketing, identify waves of functionality that can be employed during the release and used as field trials. Develop probabilistic delivery curves.
Team chartering is led by the Scrum Master and the Product Owner jointly. The objective is to establish roles and responsibility for the team members and both solicit and achieve their buy-in. To reduce the tendency for this to become a lecture, it is often useful to start with roles, responsibilities, and introductions. Even though everyone probably knows each other, start the chartering process with an opportunity for each functional group, by function, to introduce themselves. Specifically, you should ask the individuals to state what they would like to get out of their work on this Release – I would like to become more aware of our database design, I would like to be able to proctor the field trial, I would like to better understand what Quality Assurance really is, I would like to write an article on our process, etc.. Having everyone understanding where individuals want to go will help the team achieve their personal goals.
Next, the Product Owner should present the chartering deck that had been presented to Executive Management while seeking the charter. During this presentation, the order should be slightly different, so that the presentation concludes through the Scope, Estimates, Technical Vision and then the Assumptions. This is so that the team can have this pertinent data fresh in their minds while they listen to the assumptions. Once the material has been presented, the floor should be thrown open with the single question: Given these assumptions and this approach, can you accept these estimates within our anticipated (and stated) statistical variation? If the team can not they must, as a group, understand why they do not feel able to accept the estimates (the book of work), and then review and revise the plan until they are able to accept a similar charter. Before work can begin, this modified charter will need to be represented to the Executive Team to reset expectations. If not concurrence can be made, the Product Owner must go back to the Executive Team and let them know that the Team will not accept the undertaking.
What are the chartering steps prior to each Sprint?
Once the Release has started, the team must revisit the Charter prior to every sprint. The purpose of this is to revisit the assumptions that were made initially and to determine if any have changed. If they are no longer valid, adjustments may need to be made to the plan. Additionally, it is useful to review the risks and their mitigation based upon experience and new information.
Operationally, I recommend opening each Sprint Planning meeting with a representation of the Scope and Assumption slides from the Charter, as well as a Release BurnUp chart representing how our actual velocity projects out against our current accepted scope (based upon current estimates). If things have changed with scope or assumptions, we will need to understand how that reflects back through our productivity trends as well as the attainment of our Release goals. Actual content of the sprint may change based upon these realizations.
We have just finished our first sprint. What happens if we didn’t finish everything?
Unfinished work is considered Hangover. This can include anything from work that proved to be more complex than anticipated and hence too longer to complete, to work that remained unverified due to illness in the QA team, to something that the Team felt they completed but the Product Owner was not able to accept without modification. All stories that are not done are put to the top of the list of stories for the next sprint. Prior to committing them to the sprint backlog for the next sprint; however, the product owner has the opportunity to examine them, their value and risk at this point in the release, and move them out of the sprint backlog to the product backlog for later completion. Though this does not often happen, where it does come into play frequently is when there is going to be an interim sub-release and stories that don’t actually make it into the field then may have substantially lower priority than some others that are coming up later.
How do I calculate velocity?
Velocity is a measure of team productivity against the release/sprint goals. It should not be used to measure individual productivity because the statistical variation of a single data point does not produce an accurate representation. Additionally, it is important to remember that when we say productivity against goals, we do not mean to insinuate that people are not doing work if their velocity is low, we just mean that their progress against the project goals is slower, most likely because they are doing other things for the company, not directly translatable to the project goals.
Therefore, Velocity is the sum of the units (ideal days or hours) estimated for all the tasks undertaken and completed during the sprint divided by the total number of units available to the team to produce deliverable work. Velocity is a unit-less percentage. Here is an example:
A team of 7 using 3 week sprints took on 8 stories whose rolled up tasks summed to 300 ideal hours. Unfortunately one of the developers was sick for a couple of days and the team was not able to complete the story which included the tasks he was working on. The 7 stories that were completed and marked done by the product owner represented only 230 ideal hours. Though the remaining story is only perhaps 20 hours shy of completion (development and verification), none of its work can be taken credit for, as it can not be incorporated into a working baseline. The team of 7 had 840 available hours to work over the sprint. This produced an effective velocity of 230/840 or 27.3%.
Using this as a reference to yesterday’s weather, the team would be recommended to take on between 230 and 300 ideal hours, based upon the groups of stories being selected by the product owner. You would not push down to 230 immediately, as this sprint may have been struck by bad luck (wrong person working on the wrong story getting sick at the wrong time), but the trend must be looked at and if insufficient margin has been included to take into consideration historical sick time, the objectives should be ratcheted back a notch.
posted by mgelbwaks at 2:11 PM
0 Comments:
Post a Comment
<< Home