Search

Agile Filter

How Not to be Agile – Ultimate Guide to Sprint Planning

IntroductionHello and welcome to this, the fourth article in the series ‘How Not to be Agile’‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.It is the planning, content and management of the Sprints that is important.I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.Product Development TimeboxesFigure 1 represents how an Agile product development is split into different timebox levels:The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.The content of each Release is developed in a series of Sprints, more of which below.The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!Suffice to note here:The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.What is a Sprint?For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.Sprint Planning DefinitionThere is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.Sprint Planning AttendeesIt is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.Sprint GoalThis is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:“The Sprint Goal is to complete as many of the payment methods as possible”For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in oneSprint unless there was a great deal of reuse from other products.  Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}Case Study 1:In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the SprintBacklog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.Lessons:By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areasBy expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.Sprint Planning Inputs1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:High-priority changes required to previously developed PBI; unlikely but not unheard of.Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.Additional PBI that need to be added to the Product Backlog.3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issueProbable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.Sprint Planning Process1) Establish Probable Sprint2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:A) Implement any risk mitigation work in order to prevent the issue.B) Plan what to do if the risk does create an issue.C) ‘Ignore’ the risk if the probability of it causing an issue is low.Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.Case Study 2:For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.LessonsAlways take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.2) Establish the Sprint GoalSee above.3) Choose Probable Sprint PBIThe Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.Create and publish the Sprint Plan.The team members decide who will do what and when and create the Team/Sprint Board (kanban).4) How Long Should Sprint Planning Take?There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.Case Study 3:The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 aboveThe Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.There was no Risk Register.There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.Each team’s Sprint Planning process consisted of:Looking at the next PBI and breaking them down into tasksEstimating the tasks in timeSelecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.Lessons:When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practicesIf, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.Sprint Planning Output – The Sprint PlanThe Sprint Plan shows:A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.A reminder of the Sprint Review date, time and place.The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.What the Sprint Plan is NotThe Sprint Plan is not:A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team onlyThe Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.Case Study 3:Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:Q.  “How often can the Sprint Plan be amended?”A.  “Every day”Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.Lessons:Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.ConclusionEffectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:The ‘Product Owner’ must set the Sprint Goal.All factors influencing the expected team Sprint Velocity must be considered.Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.The Sprint Plan is for the management and stakeholders.The Team/Sprint Board is for the Development Team.

How Not to be Agile – Ultimate Guide to Sprint Planning

598
  • by Steve Ash
  • 08th Oct, 2018
  • Last updated on 11th Mar, 2021
  • 4 mins read
How Not to be Agile – Ultimate Guide to Sprint Planning

Introduction

Hello and welcome to this, the fourth article in the series ‘How Not to be Agile’

‘How Not to be Agile’ may seem a strange title for blogs about how good Agile is!  What I intend to do over this series of articles is to share with you the misinterpretations, omissions, and mistakes that people make that significantly reduce the potential benefits when an organisation, or part of it, embark on an Agile Transformation.

Last time, I discussed the potential pitfalls with respect to the Product Backlog; this time, I will cover some of the misunderstandings and malpractices that I have come across to do with the ‘development timebox’ planning.  The most often used term for the ‘development timebox’ is the Sprint from Scrum; I will use this and other Scrum terminologies in this article but you can use whatever names you like; I shall put single quotes around Scrum role names to indicate that other names may be used.

It is the planning, content and management of the Sprints that is important.

I will start with a description of how product development is split into different time periods and then focus on the Sprint Planning ceremony.

Product Development Timeboxes
Product Development, Releases and Sprints

Figure 1 represents how an Agile product development is split into different timebox levels:

  • The ‘complete’ product development is a timebox; it has a fixed end date; there may be maintenance periods after the product development is ‘complete’.
  • The features of the product ‘go-live’ in a series of Release timeboxes, the content of each release contributing to the business benefits expected; usually, between 2 and 3 months.
  • The content of each Release is developed in a series of Sprints, more of which below.
  • The production of the artifacts produced in each Sprint may be timeboxed as well if appropriate.

There are other ‘models’ that are used; some teams release at the end of each Sprint; Google is set to release new or modified functionality about every minute!

Suffice to note here:

  • The ‘High-Level Requirements Analysis’ in the Product Development line represents the activities that I covered in the first articles of this series.
  • The Release timeboxes need to be decided before the development work starts.  It is useful if all Release timeboxes are of the same length but in practice, the first is usually longer than the rest and the last, shorter than rest; it depends on the product and organisation.

What is a Sprint?

For those who have heard the term ‘Sprint’ but not quite sure what it means, a Sprint is a fixed period of time in which ‘requirements’ are developed from the name to a fully working part of the final product, all done by a fixed size team (see ‘How not to be Agile 3. Product Backlog’ {Insert link to published article} for discussion about ‘The Iron Triangle’)’

Having achieved an agreed, prioritised and estimated Product Backlog, the Development Team need to decide how long their Sprints will be; usually 2 to 3 weeks but can be as short a one week or as long as 4 weeks depending on the organisation’s circumstances and the nature of the product to be developed.  If it is thought necessary to have Sprint lengths greater than 4 weeks, then an in-depth analysis of the reasons for this must be made and changes, probably to the organisation, must be implemented so that the Sprint lengths can be reduced; more than 4 weeks between wider stakeholder reviews are too long and can lead to a lot of wasted work.

It is worth noting here that once the Development Team has chosen their Sprint length, it remains the same for the whole product development unless something major happens which requires a change to release plans. Let’s see the purpose and steps for an effective Agile Sprint Planning.

Sprint Planning Definition

There is a popular myth that Agile requires no planning; the ‘Nike’ approach –  ‘Just Do It’.

Nothing is further than the truth; there are more planning ‘events’ in any Agile framework than any waterfall method that I have come across; we just plan at different levels.

The first ‘ceremony’ of any Sprint is Sprint Planning  whereby the Development Team agree with the ‘Product Owner’ what the Sprint Goal is and which Product Backlog Items (PBI), that will contribute to that goal, will be attempted during the Sprint.

Sprint Planning Attendees

It is important that all of the Development Team, both full and part-time, the ‘Scrum Master’ and the ‘Product Owner’ attend the Sprint Planning as a minimum:

The ‘Product Owner’ needs to be there to set the Sprint Goal, agree the PBI to be attempted in business order and agree on the Sprint MVP.

The whole Development Team needs to be there because all team members have to agree on the Sprint Plan; if any team member is absent, he/she may feel that the work has been ‘foisted’ upon them and will have reduced motivation to do it.

The ‘Scrum Master’ needs to be there to listen to the conversations so that they can keep a ‘fly on the wall’ view of the team during the Sprint and remind any team member that may be straying from the plan.

Sprint Goal

This is a widely misunderstood part of Agile; there are many organisations that think that the Sprint Goal is to complete all the chosen PBI; it is not.

A Sprint Goal helps the Development Team focus on a narrow aspect of the overall product, for example:

“The Sprint Goal is to complete as many of the payment methods as possible”

For a ‘retail’ website, there may be many possible payment methods such as credit/debit cards, PayPal, WorldPay etc.  There will no doubt be some ‘common’ aspects to all payment methods that will need to be developed and each method will have its own ‘specialised’ aspects; it is unlikely that all payment methods could be developed in one
Sprint unless there was a great deal of reuse from other products.  

Therefore, the customers’ most preferred payment methods may be in the Sprint’s MVP; others that cannot be completed in the Sprint go back into the Product Backlog in their respective business value order for consideration in later Sprints.

You can think of a Sprint Goal as the Sprint Vision similar to the Product Development Vision that I discussed in the first article in this series. {Insert link to published article}

Case Study 1:

In one organisation that I coached in, when I arrived, they did not have ‘Sprint Goals’.  The teams worked out their capacity and ‘filled’ the Sprint with PBI estimated to fit that capacity.  The ‘Sprint Goal’ as far as management was concerned was to complete all the PBI in Sprint that was chosen during Sprint Planning.

What you have in this situation is fixed time, fixed team and fixed requirements; recognise that? It’s a Waterfall.

Because, like all of us, the team members were not that good at estimating, were reliant on external resources that it had no control over and did not know all the Sprint

Backlog Items (SBI) at Sprint Planning , the teams consistently ‘failed’ to complete all the Sprint Planning chosen PBI  in the Sprint.

The immediate consequence of this was management ‘getting on the teams’ backs’ for not working hard enough.  Morale sank and the team members blamed Agile!

The teams learned to ‘game’ the PBI estimating by increasing estimates so that less PBI were chosen at Sprint Planning.  One team even marked unfinished PBI as complete at the end of the Sprint and then ‘resurrected’ them for the next Sprint.

Lessons:

  1. By not having a Sprint Goal, the ‘Product Owners’ lost the chance to focus Sprint development incoherent areas
  2. By expecting Development Teams to complete all published SBI within the Sprint, team morale dropped, the team members blamed Agile and they focused on making themselves look better in the eyes of management rather than producing the best business value.

Sprint Planning Inputs

1) The Product Backlog:  The initial estimation of the next most important PBI to contribute to the Spring Goal was probably done sometime before Sprint Planning; the Development Team will have learned a lot from previous Sprints so those initial estimates may be way off.

Most teams carry out Backlog Refinement during a Sprint to make sure that the next most important PBI are ready to be considered for the next Sprint; I will discuss Backlog Refinement in a later article.

If Backlog Refinement is not done separately, it must be done as part of the Sprint Planning.

2) Review Comments from the previous Sprint:  There may have been comments of the development to date from the previous Sprint Review session that may affect what needs to be done in the current Sprint.  These may include:

  • High-priority changes required to previously developed PBI; unlikely but not unheard of.
  • Changes to organisation strategy or tactics that mean necessary changes to Product Backlog ordering.
  • Additional PBI that need to be added to the Product Backlog.

3) ‘Inspect and Adapt’ Improvements:  The last ceremony of any Sprint is the Retrospective where the team discusses possible improvements to the process they are following and make prioritised plans to implement the improvements.

The process improvement items must be considered when the team decides on what is possible in the Sprint; new processes sometimes slow production until they ‘bed-in’.

4) The Risk List/Register: One Sprint Planning input that is mostly overlooked is the Development Risk List/Register.  Without going into the detail of Risk Analysis, one of its aspects is to determine when a particular risk may become an issue

Probable risks need to be considered during Sprint Planning because any mitigation work that needs to be done will reduce the number of PBI that may be attempted.

Sprint Planning Process

1) Establish Probable Sprint

2) Velocity Sprint Planning starts with the team deciding what their Sprint Velocity is expected to be from the following:

  • Team Sprint Capacity: For most Agile teams, their Sprint capacity is based on the team’s Velocity; the average number of Story Points completed over the last 3 or 4 Sprints.  

    For organisations ‘wedded’ to time estimation, the team’s Sprint capacity is the number of team members multiplied by the number of working hours in the day multiplied by the number of working days in the Sprint.

    For teams using Velocity to estimate their capacity, any team member absence during the Sprint must be used to reduce the Velocity with which to plan the Sprint.

  • Risk Analysis:  The Risk List/Register must be reviewed to see if any of the risks may become issues during the Sprint.  If so, then decisions must be made whether to:

    A) Implement any risk mitigation work in order to prevent the issue.
    B) Plan what to do if the risk does create an issue.
    C) ‘Ignore’ the risk if the probability of it causing an issue is low.

Again, if the team consider that significant work must be done for managing any risks, then the team Velocity must be reduced to account for the risk management work.

  1. Review Comments:  The team must inspect the Review Comments from the previous Sprint Review to see if any remedial work is needed.  If so, the work must be estimated and, again, the team velocity must be reduced.
    Ideally, Review Comments that necessitate remedial work should become PBI and ordered by the Product Owner before Sprint Planning; if this is the case, there is no need to reduce the team’s Velocity.
  2. Inspect and Adapt:  If the team has decided that they will attempt process improvements during the Sprint, it needs to consider if any of these improvements will cause extra work and if so, what effect the extra work may have on the team Velocity.
    You may think that process improvements should result in a higher Velocity; however, if the process improvement is to do with getting better quality, then the Velocity may go down.

Case Study 2:

For one engagement, I was working as an analyst/designer and I raised a concern with the ‘Agile PM’ that I could not find the Risk List/Register so that I could add risks as they came up.  He was wary about adding risks because he believed that people would perceive that the more risks there were, the less he was capable of doing his job!

After persuading him to let me see the Risk List, I found it to be wholly inadequate; the risks in the List were few, they weren’t ordered and there was no indication of impact severity, probability of becoming issues or when they may occur; there was no mitigation in place for any of them.

I persuaded the ‘Product Owner’ that we should have a Risk Workshop with the Development Team and stakeholders.  At the end of the half-day workshop, we had a pretty good Risk List.

BUT – the ‘Agile PM’ insisted that he, as the Risk and Issue Manager, would have sole control of it; he would not let anyone see it except himself!

As time went on, not being able to see the Risk List, we in the Development Team could not take potential risks into our planning and when risks did turn into issues, we couldn’t see the agreed mitigation.  Progress slowed.

Lessons

  • Always take time before development starts to get a good Risk List/Register not just including the ‘normal’ risks but also including the risks of being Agile in an organisation just beginning to transform.
  • By all means, have the Agile PM/’Scrum Master’ being the sole ‘controller’ of the Risk List; all new risks and changes to existing risks must be passed through the Agile PM/’Scrum Master’ just like the ‘Product Owner’ controls the Product Backlog.
  • The Risk List/Register must be available to the Development Team at Sprint Planning to adequately estimate its Sprint Velocity.

2) Establish the Sprint Goal

See above.

3) Choose Probable Sprint PBI

  • The Product Owner should initially choose the next most important PBI that will satisfy the Sprint Goal.
  • The Development Team compare the revised Sprint Velocity with the total Story Points for the initial chosen PBI.
  • The Development Team negotiate with the Product Owner to get the agreed SBI and the Sprint MVP; I discussed the MVP for the Product Backlog in my previous article, ‘How Not to Be Agile 3. Sprint Backlog’; the process to determine the Sprint MVP is the same as for the Product Backlog MVP.
  • Create and publish the Sprint Plan.
  • The team members decide who will do what and when and create the Team/Sprint Board (kanban).


4) How Long Should Sprint Planning Take?

There is no definitive answer to this question; it depends on the team, the product and the environment.  However, empirical observation of ‘successful’ teams indicates that for a 2-week Sprint, Sprint Planning should take between 2 and 4 hours.

Case Study 3:
The worst example of ‘non-Agile’ Sprint Planning that I have come across is with the same organisation that I spoke about in Case Study 1 above

  • The Product Backlog was filled in a ‘first come, first served’ order unless a ‘show-stopper’ turned up.
  • There was no Risk Register.
  • There was no Sprint Review Comments because there was no business representation at the Sprint Reviews.
  • There was no ‘Inspect and Adapt’ plans because the teams didn’t really know what Retrospectives were supposed to be for; they held them because they were told to but they used it as a ‘team meeting’ chat.

Each team’s Sprint Planning process consisted of:

  • Looking at the next PBI and breaking them down into tasks
  • Estimating the tasks in time
  • Selecting the PBI whose total estimated time added up to the team’s Sprint time capacity; senior management had ‘allowed’ a ‘contingency’ in that the Sprint time capacity was 80% of the total team time capacity.

However, the team member’s task estimation was not done with any enthusiasm because they knew that ‘requirements’ would be arriving in the Sprint that represented between approximately 10% and 50% of the their capacity; there was no pattern to this extra work that could be used to modify the team’s Sprint capacity.

What was worse was that senior management measured teams by the number of Sprint Backlog Items (SBI) that had been published in the Sprint Plan; the published list was never completed because of the ‘break-ins’.

Each team was taking between 6 and 8 hours to complete Sprint Planning; producing a Sprint Plan that they knew would not work!

I asked the teams if they thought their Sprint Planning was ‘reasonable’.  The answer worried me greatly.  The culture of the organisation was ‘what the management wants, the management gets’ and the teams had been used to criticism for years.  The Agile transformation, instigated by the senior management, was an attempt to change this situation but all of the management had probably had less training than the teams.

Lessons:

  1. When finding ‘bad’ practices in teams, find out the root cause of the ‘bad’ practices
  2. If, as a ‘Product Owner’, ‘Scrum Master’ or Agile Coach, you do not have access to senior management, introduce a ‘disruptive experiment’; devise an effective Sprint Planning process for one team and when the management ask why things are so different, you will get the access to the management that you need to explain why their ‘edicts’ were probably less than optimal and possibly misinterpreted by the teams.

Sprint Planning Output – The Sprint Plan
The Sprint Plan shows:

  • A list of ordered PBI that will be attempted during the Sprint (the SBI) along with the Sprint MVP.
  • A list of workshops that need to involve people outside of the Development Team with the people needed; the list includes dates, times and places for the workshops.
  • A reminder of the Sprint Review date, time and place.

The Sprint Plan is published to ALL stakeholders including those who will be required to help during the Sprint.

What the Sprint Plan is Not

The Sprint Plan is not:

  • A detailed, day-by-day Gantt Chart of tasks:  What the team does in the way of tasks is for the team only
  • The Team Board – Whether it is ‘Sticky Notes’ on the wall or an electronic representation of that, the Team Board is updated at least daily;  unless something major happens, the Sprint Plan is not changed after publication.

Case Study 3:

Unfortunately, there is one Agile ‘standards’ organisation that occasionally has a question in its certification exams:

Q.  “How often can the Sprint Plan be amended?”
A.  “Every day”

Rationale.  “The Team Board is updated at least every day during the Daily Stand-up”

I guess the organisation has the right to equate a Sprint Plan with the Team/Sprint Board but this has the effect that management and stakeholders need to look at the Board to see what the ‘current’ plan is; they cannot help but interpret the Board with some aspect of Sprint progress and if they do not like what they see, there is a temptation to intervene with the team.

Lessons:

  1. Progress within a Sprint should be solely the responsibility of the Development Team facilitated by the ‘Scrum Master’.
  2. Remember – the sole measure of Sprint success is that the SBI representing the MVP have been completed.

Conclusion
Effectively preparing for Sprint Planning, following the best practices of Sprint Planning is essential for Sprint success:

  • The ‘Product Owner’ must set the Sprint Goal.
  • All factors influencing the expected team Sprint Velocity must be considered.
  • Initial estimates of PBI done when creating the Product Backlog must be verified in the light of experience gained so far.
  • The Development Team must agree with the ‘Product Owner’ which PBI to take into the Sprint Plan and agree on the Sprint MVP.
  • The Sprint Plan is for the management and stakeholders.
  • The Team/Sprint Board is for the Development Team.
Steve

Steve Ash

Blog Author

Steve Ash has been working with ‘Agile’ since 1993 when it was known as ‘Managed RAD’.  He was an early adopter of the DSDM Framework in 1995 becoming a DSDM Board Member in 2002 and was a DSDM examiner.  He is a DSDM Advanced Practitioner and Accredited Trainer/Coach. Steve has since embraced Scrum, Kanban, the techniques advocated by XP, Lean Software Development and Lean Startup. He joined the Agile Alliance in 2002 and is a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), SAFe® Certified Consultant (SPC4) and certified by APMG International to teach Agile Project Management and Agile Business Analysis courses. Since 1996, Steve has trained, mentored and coached hundreds of people in many public and commercial organisations in 11 countries from the USA, through Europe and India to Asia/PAC.
 

Join the Discussion

Your email address will not be published. Required fields are marked *

1 comments

Donald Hope 16 Nov 2018

Very circumstantial info Thanks.

Suggested Blogs

How To Define Features in Agile Methodology?

Agile projects are known for their simple, iterative approach to cutting through the complexity. Even the most ambitious of Agile projects is taken one step at a time and breaks down complex work packages and tasks into low-level subtasks. Features and capabilities that are needed in the finished product are listed out, and then broken down to manageable chunks which are taken up and completed, one at a time.Image SourceIn this article, we will talk about Features in an Agile project. What are the characteristics of features and how are they applied? How do you build a feature list, and what are the advantages of breaking down features into user stories? Read on to find out!Agile projects are known for their simple, iterative approach to cutting through the complexity. Even the most ambitious of Agile projects is taken one step at a time and breaks down complex work packages and tasks into low-level subtasks. Features and capabilities that are needed in the finished product are listed out, and then broken down to manageable chunks which are taken up and completed, one at a time.In this article, we will talk about Features in an Agile project. What are the characteristics of features and how are they applied? How do you build a feature list, and what are the advantages of breaking down features into user stories? Read on to find out!What is a feature in Agile methodology?A feature is a service or function of the product that delivers business value and fulfils the customer’s need. Each feature is broken down into several user stories, as it is usually too big to be worked on directly. A user story is an informal, short description of a part of a software feature that is written from the user’s perspective and talks about how this particular bit of the feature will offer something of value.Why use features in Scrum and not only user stories?A feature is something that is sizeable enough to deliver measurable value to customers and creates a large chunk of functionality. Features are used to describe the functionality at a macro level, and they are required to create schedules and plan the high-level release of the product.Scrum works on the premise of short development cycles called Sprints, which usually last between 2 weeks and a month but not longer. One feature is typically completed over several sprints. In one sprint, only several user stories can be completed and not, perhaps, an entire feature.What’s the difference between features and epics in Agile?The product backlog is usually detailed into three levels of complexity with respect to tasks. Epics are large quantities of related work that can be broken down into features. A feature, as we have seen, is a service or function that delivers value to the end user. Each feature is broken down into a number of smaller and simpler tasks known as user stories. Do note that for a smaller project, with only around 8 to 10 people on the team, the product backlog may be divided into just features and user stories. Epics come into the picture for large projects with multiple teams who are working over a duration of several years.Who writes the features in Scrum, and what are the steps involved?The Scrum Guide, considered to be the Bible for all things Scrum, does not lay out any guidelines for the use of features.However, Scaled Agile, Inc. indicates that the Product Manager is the owner of the Features, which is to say, he or she finally decides what goes into the feature and what is its priority on the Backlog. The features are not necessarily written by the Product Manager, however, and this could be done by others on the team.On many teams, the Product Manager and the Product Owner are one and the same.There are several steps in the definition and writing of features. Define the WHY, or the benefit hypothesis: What is the functionality that the users gain from the feature? What are the benefits to be gained from implementing this feature? Calculate the business value: Keep in mind the number of users, how often each of them uses the feature, what is the timeframe within which the feature must be released for it to be useful, and how much effort goes into developing this feature. All these together will help to determine the ROI of the feature and ultimately whether it is worth the effort and cost. Features that bring in the most benefit at least cost will be prioritised. Describe the feature: What is the context and how will it be used? What is the need for the feature? Try to include technical details and any information that is important from the Product Manager’s point of view. Write down the acceptance criteria: What are the conditions under which the feature can be deemed to be done? This will help to reduce any ambiguity and mark work progress. How big should the product features be?While there is no hard and fast rule on this, and it is left largely to the convenience of project teams, it is generally agreed that it should be possible to complete a feature within a maximum of three months. When using SAFe, a feature is released in one single program increment. Teams that are working with investor funding and are getting the funds at regular cycles should be able to showcase a completed feature during each investment cycle, in order to demonstrate that they are progressing on track. What are feature points?Feature points represent the amount of the work complexity, effort taken, and knowledge required to complete one feature. They are the same as story points, but in the context of a feature rather than a user story.What are features called in different Agile Methodologies?A feature, while essentially having the same definition, could be called by different terms in different Agile methodologies. In Scrum, a feature is often referred to as a Backlog Item.   In XP, features are called Stories. DSDM terms a feature as a requirement. This could club together several system features. Agile UP defines features in the form of requirements and use cases.What are the characteristics of features?To be effective, a feature should always Offer measurable business value,   Contain enough information to allow for estimation of the work involved, Be small enough to be completed within a program increment or maximum of three months,   Be testable by the scrum team and the product management team.Feature breakdown structure (FBS)When getting into the nitty gritty of detailed planning, agile development uses a feature breakdown structure (FBS) approach that breaks down each feature into smaller, more manageable units of work. This allows easier communication between the customer and the development team, where both can understand each other well in a way that leaves no room for ambiguity. It also helps to track the progress of work against the value that is created. Over time and as the work progresses, the larger features can be broken into smaller features, instead of doing this breakdown all together in the beginning. This way, details are not fleshed out until the time when they are actually needed for design and delivery. Building an initial feature listAt the very start, before the release planning and iteration planning can happen, the team must sit together and list out as many potential features for the system as possible at this stage. Feature requests can come from many sources, and one person should be allocated to collate all these requests. While this could be the product manager, it could also be a customer proxy, a business analyst or someone who is responsible and accountable to the team. The team should refine these requirements, weeding out duplicate items, features that are not possible to implement, and requests that are very vague. As the features are identified, they are added to the list so that they can become a part of the planning processes. This initial feature list can be considered to be a preliminary outline that can be used as input to chart out the release and first iteration. It is not required to wait until all features are defined before getting started on the actual work, and it is also understood that the original list, descriptions, and priorities will evolve over time. Instead of waiting for everything to get detailed out at the outset, the team can get to work with the initial list without wasting any valuable time. As new features which could be critical get identified, they are simply added into the evolving release plan and will get delivered during a subsequent iteration. As the project progresses, the work adapts itself to accommodate new priorities, additional information from stakeholders, and the changing industry dynamics.Advantages of breaking down features into smaller user storiesUser stories, as we have learnt, represent smaller chunks of work while features represent fully formed functionalities of the product. There are many advantages to breaking down the features into functionalities, and the main ones are these: Stories narrow down the focus: Stories are small, doable portions of the work that do not overwhelm the developer. They represent an entire piece of functionality, however small it is, and so can measure incremental progress. Stories fit into a sprint: Features are too large to be completed within a sprint, but stories can be finished within this duration. This allows more efficient scheduling and planning of sprint tasks. Stories capture both intent and outcome: A product manager (who is not required to be technically fluent) can easily describe the outcome of a story to the developer, so that he or she can understand the intent. Stories mitigate the risk: As big stories come with a lot more complexity, they also involve more risk. When features are broken down into smaller stories, this risk is mitigated. Anny erroneous assumptions can be curtailed within a few days rather than several weeks into development. Feature vs. task planningFeatures come into play at a macro level of planning, and it is essential that at a later point they will need to be broken down into tasks and estimated. This is done during sprint planning and release planning.Feature planning and estimates help to schedule releases and iterations. Task planning and estimates help to allocate resources and plan the tasks within an iteration.Since the nature of agile project plans is always fluid and not very precise, feature estimates need not exactly map to a number of task estimates, but there should be a rough approximation between the two.
7342
How To Define Features in Agile Methodology?

Agile projects are known for their simple, iterati... Read More

Scrum Software for the Ultimate Project Management

Technology has made our lives easier. The number of tools and devices we have at our disposal has made our lives more productive and our work more efficient. The Agile software development methodology has been adopted by several organizations to improve their adaptability, responsiveness, and productivity.  How can we improve the way we incorporate Agile Scrum into our projects? Scrum tools can be the answer. Just like the other gadgets in our lives, Scrum software and tools help improve the productivity of our teams, keep stakeholders happy and help us deliver better products. Before we jump into the use and needs of Scrum software and tools let us understand more about Scrum roles and how they work.Three essential roles for Scrum successThe Scrum Guide defines three pillars of a Scrum team, which include:The Scrum MasterThe Product OwnerThe Development TeamThe Scrum team is a small unit which is self-organised and works towards achieving the same goal; that is, the development and deployment of the product and customer satisfaction.The Scrum Product OwnerThe Scrum Product Owner is among the most essential roles in the Scrum team and acts as a bridge between the stakeholders and the development team. More involved with the business side of the software development process, the PO represents the customer and can be considered as their proxy.  The Product Owner defines the product vision, and, along with the Scrum Master and the development team works towards delivering a product that matches stakeholder needs.The Scrum MasterThe Scrum Master is the servant leader whose main responsibility is to ensure that the Scrum team can perform to the best of its abilities. They do this by overseeing the day-to-day activities of the Scrum team and removing any impediments that may hinder the productivity of the development team. The Scrum Master facilitates stakeholder collaboration along with the product owner and ensures that teams can handle complex environments and deliver projects successfully.The Scrum development teamThe development team generally consists of three to nine people, according to the Scrum Guide. These would include developers, testers, designers and more. The team is allowed to take decisions and decide the length of the sprint and how they will go about it. The development team collaborates to create a high-quality product increment at the end of each sprint that is as per the expectations of the stakeholders.Scrum ceremonies or eventsScrum has five formal events as defined by the Scrum Guide. These events help to validate the Scrum artifacts and implementing them helps enhance transparency. The events are also called ceremonies and are:Sprint PlanningDaily ScrumSprint ReviewSprint RetrospectiveThe SprintWhat Does A Scrum Tool Do?What would you need a good Scrum tool to do? Make your life easier by making processes more efficient and less cumbersome, help you deliver quality products without making a huge dent on your budget, right?  With Scrum topping the popularity charts for Agile project management methodologies, the need for efficient Scrum tools has risen. There are plenty of Scrum tools available that fit the bill and provide interfaces that help teams seamlessly follow Scrum processes and reap its benefits. These tools help:Increase productivityIn task management, daily scrum management  Increase team collaborationIn progress tracking and risk managementScrum Software for the Ultimate ProjectThere are several Scrum software tools that aid in project development using Scrum; not just in technical environments, but in non-technical sectors as well. Software like JIRA, Infinity, TargetProcess, QuickScrum, Wrike etc provide:User friendly GUICompetitive pricingProduct backlog managementTime tracking and calendar tools for schedulingScrum metrics and chartsSprint planning toolsThird party tools for integrationUser story mappingBurnup and Burndown chartsand many more features that will help Agile teams serve their customers better, improve return on investment, reduce costs, enhance collaboration and ensure stakeholder satisfaction. These tools help team uphold the values of Agile and make implementing the Scrum framework easier.Best Scrum ToolsHere are some of the best Scrum tools available in the market:1. JIRAJira is a popular tool used by large organizations to manage their Scrum projects. It has numerous features including customizable scrum boards, reporting features and more. Here’s how teams benefit from this toolCustomizable Scrum and Kanban boardsRoadmaps to communicate with team and with stakeholdersAccess to tools for Agile reportingView of code and deployment statusEnd to end DevOps visibilityEasy scalabilitySecure deploymentDeveloper tool integrationRich APIs to automate processes2. TargetProcessThis tool has been especially designed for teams that want to scale agile. It offers a number of customizable features that make it easy to work with scrum and agile.  Here’s how teams benefit from this tool(Source: Targetprocess Agile Portfolio and Work Management Tool)IdeationBuilt in reports to analyse data and uncover trendsGather ideas across sourcesCloud hosting and on-premise hostingEnterprise grade securityCollaborate across the enterprise  Collaborate with DevOps tools including GitLab, Azure DevOps, GitHub etc3. VivifyScrumThis tool is marketed as an all-in-one solution to manage projects, collaborate and track. Here’s how teams benefit from this tool (Source: Agile Project Management Software - VivifyScrum)Tools to manage agile projects—organize, manage, track and deliverCollaboration boards to effectively collaborate with team and stakeholdersCreate invoices to track and manage business and clientsManage teams and track tasks4. InfinityThis tool is among the most popular in Agile and Scrum organizations due to the many customizations and features it provides. Its various tools help reduce time to market, ensure better quality, improve collaboration and enable customer satisfaction.Here’s how teams benefit from this tool Source: Infinity | Customizable Work Management Platform (startinfinity.com)How Can Scrum Apps Benefit Your Team?The number of Scrum apps and software available in the market for Scrum projects is mind boggling. Which one you choose depends on the requirements of your team and project, and each comes with its own benefits. Some of these benefits include:They help teams, organizations and the product being createdThey ensure better quality by providing the right framework, support mechanism and the right processesAllow for continual improvement by putting in place a feedback loop and sprint reviews by stakeholdersHelp solve impediments and daily issues by incorporating daily testing and product owner feedback into the development processEnsure upfront documentation and help prioritise high value items in the product backlog, thus decreasing time to market.  Quick feedback also helps improve the product and thus helps in continuous improvement.The faster marketing of products increases return on investment, helps tap the market demand and ensures long term benefits for the customer and thus earns their trust for the organizationThe primary tenet of Agile is team collaboration. Scrum software tools help in high level collaboration between the Scrum Master, Product Owner and the development team. Teams can organise, review, plan and discuss everyday tasks, meetings, impediments and more.How to Pick the Best Tool for Your Team?With so many options available, choosing the right Scrum tool for your team can be a tricky task. What you need to do is go through the features of the best tools and see which one best fits your requirements. While the number of features you get will be directly proportional to the money you are ready to pay for the tool, there are some basic requirements your tool must satisfy.Backlog creation:  The very basic format of a Scrum project lies in the creation of a product backlog which sets the pace for the entire project. The backlog is primarily created by the Product Owner with assistance from the Scrum Master and the development team. The tool you choose should help you create the product backlog so that you can prioritise items, define the sprints and identify sprint goals.Implement feedback:  Scrum projects are based on the Agile values of continuous feedback. Your scrum tool should have features which will make your customer’s feedback and requirements easily accessible to you. This will help you implement these changes at the earliest. This continuous feedback loop will help keep customers happy.Sprint creation:  Scrum is iterative and adaptive and works by breaking down projects into small sized sprints. Your tool must aid you in the creation of sprints and burndown charts. These help you keep track of your progress on the project and are essential components of a Scrum project.The other things your tool should be able to do include:Plan and trackCustomise process templatesCustomise dashboards and reportsHelp in time managementHelp create epics and storiesProvide collab and reporting toolsProvide review toolsAnd just like you will create a product that is user friendly, the tool you use also needs to be user friendly for the team. If your team is happy using it, and it makes your life easier and your projects better, then you have the right tool!
Scrum Software for the Ultimate Project Management

Technology has made our lives easier. The number o... Read More

What Best Describes a Scrum Team?

We are living in an age where speed is the secret to success, and the one who gets the product out first is the winner. In this digital transformation world, organizations that have adopted Agile will succeed; as Agile is all about adaptability, quick delivery and customer focus.  Scrum, the most used Agile framework is all about addressing complex problems through adaptation and value creation. Scrum teams are at the core of a Scrum project. What best describes a Scrum team? Let’s attempt to answer this question.What is Scrum?A term borrowed from rugby; Scrum actually means ‘to huddle’. It signifies how rugby payers huddle together and work as a team in order to gain possession of the ball. Like its namesake in the sport of rugby, Scrum in Agile software development also signifies a process that brings together a team of individuals who work together under complex circumstances to create a product. The term was first used by researchers Hirotaka Takeuchi and Ikujiro Nonaka in their 1986 research paper, "The New Product Development Game."“Scrum is a framework that encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve”—Atlassian Agile coachWhat is the Scrum Methodology?Scrum is a framework under the umbrella of agile development methodologies, along with Kanban, Extreme Programming, Feature-Driven Development, Crystal, and Dynamic Systems Development Method (DSDM).The Scrum methodology focuses on delivering products of the highest quality through effective collaboration between teams involved.  Scrum is based on the three pillars of empirical process control, which are transparency, inspection, & adaptationThe Scrum FrameworkScrum is an Agile methodology framework that follows an iterative and incremental approach for project management, and breaks down large projects into small chunks called epics and sprints.  Each sprint results in the creation of a product and the cumulative effort of all the sprints adds to the improvement of the overall end product. The Scrum framework encourages high level collaboration among team members which comes in handy in tough project situationsWhat is a Scrum Team?Scrum.org is what best describes a Scrum Team by defining it as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.’ So, in essence Scrum teams are self-organized and highly productive teams that deliver quality products in a highly collaborative environment.  A Scrum team’s success is based on the Scrum values that they share. These are:Commitment:  Commitment is one of the hallmarks of Agile teams. Teams collaborate and work on a common goal through a high degree of communication and trust between them.Courage: Scrum teams must have the courage to fail. Fail fast is a benefit in Agile and Scrum as this helps them discover hidden faults and recover quickly. Scrum teams must have the courage to try new things, innovate, fail and then learn from their failures to ultimately achieve success.  Focus: Having focus is a mandatory requirement of Scrum teams which ultimately helps them limit the work in progress.  Openness: Transparency and openness is also one of the empirical processes on which Scrum is based. Teams that are open and transparent with one another trust each other more and work better towards reaching a successful end point.Respect: Respect between team members is a must, irrespective of the methodology or framework they use. Respect between Scrum Masters, Product Owners and Development team members will help foster trust and enhance collaboration and co-operation between teammates.What describes a Scrum team?A Scrum team consists of three main roles. These are:Development TeamScrum MasterScrum Product OwnerThe development team consists of five to eleven people including developers, testers, architects and others. The Scrum team has a shared goal and through their collaboration and skills of self-organization and motivation, they reach this goal.What is a Scrum Master?The Scrum Master, also known as the servant leader, helps empower the team and guides them on the use of the Scrum framework. Their main responsibility is to ensure that the development team can perform to the best of its abilities, and they do this by removing obstacles or impediments that may hinder the progress of the development team. The Scrum Master is the agile coach and mentor who helps team members understand Agile and its processes and aids in enterprise-wide agile transformations.The Product OwnerThe Product Owner is the bridge connecting the stakeholders and the development team. They define the product vision and through their skills and intelligence drive the project with help from the Scrum Master and the development team. The product owner maintains the perfect balance between the stakeholder and the development team, helping each understand the other’s point of view. They are also well-versed in agile and scrum values and principles and guide the team and well as the stakeholders on the agile ways of working. Creating stakeholder satisfaction is an important responsibility of the product owner and they do this by ensuring that requirements are met, and the product created meets quality standards expected by the customer.The Development TeamThe development team is the driving force of the Scrum project. This team is empowered by the Scrum Master and the Product Owner to take decisions and be as autonomous and independent as possible. At the same time there is a high level of collaboration and transparency among the team members and between the dev team and the Product Owner. The dev team is balanced and helps the product owner manage the backlog and deliver an acceptable product at the end of every sprint.Why is the Scrum team required for organizations?Any organization that wants to go agile and implement projects using the scrum framework has to do so by getting together an efficient scrum team. Scrum has proven to be extremely successful at team levels and it is the Scrum team that drives the project to success. Scrum teams with their collaboration, self-organization, innovation and collocation are able to drive success and business value.A table that summarizes the Scrum Team’s responsibilities in the various Scrum processesScrum PhaseScrum processScrum Master responsibilityProduct Owner responsibilityDevelopment team responsibilityInitiate1. Create Project Vision------2. Identify Scrum Master and Stakeholder(s)--Identifies Scrum Master--3. Form Scrum TeamAlong with the PO decides dev teamAlong with the SM decides dev team--4. Develop Epic(s)Helps PO in developing epicsDevelops epics and arranges user group meetingsHelps PO in developing epics5. Create Prioritized Product BacklogHelps PO in epic refinementRefines epicsHelps PO in epic refinement6. Conduct Release PlanningHelps PO and dev team with backlog prioritization and determining sprint lengthReviews the backlog and develops release planning scheduleHelps PO with backlog prioritization and determining sprint lengthPlan and Estimate7. Create User StoriesHelps dev team and PO write user storiesWrites user stories and incorporates them into the Prioritized Product BacklogWrites user stories8. Approve, Estimate, and Commit User StoriesEstimates the effort required to deliver the product defined in each user storyApproves user stories for the sprintAlong with the SM estimates the effort for each sprint and9. Create TasksHelps dev team break down the stories into tasksHelps dev team break down the stories into tasksBreaks down the approved stories into tasks and create a task list10. Estimate TasksHelps the dev team create the effort estimated task listHelps the dev team create the effort estimated task listCreates the effort estimated task list11. Create Sprint BacklogHelps the PO create sprint backlogCreates the sprint backlog and lists the tasks that need to be completed in the sprintHelps the PO create sprint backlogImplement12. Create DeliverablesGuides the dev teamHelps dev team if neededWorks on creating sprint deliverables13. Conduct Daily Stand-upArranges and conducts the meetingsMay or may not attend the meetingsAttends the meetings and defines any problems or issues faced14. Groom Prioritized Product Backlog Helps PO to groom the backlogUpdates and maintains the backlog continuouslyHelps PO to groom the backlogReview and Retrospect15. Convene Scrum of ScrumsHelps teams collaborate and notes any impediments that may be hindering work--Mentions their progress or any issues they may be facing16. Demonstrate and Validate Sprint Helps dev team in displaying what it has createdApproves or rejects what the dev team demonstratesDemonstrates deliverables to PO and stakeholders17. Retrospect SprintMeets with dev team to ponder on lessons learnt during the sprint. Documents the recommendations--With scrum master retrospect's on sprint and uses the recommendations for the next sprint18. Ship DeliverablesAlong with other team members ships acceptable deliverablesAlong with other team members ships acceptable deliverablesAlong with other team members ships acceptable deliverables19. Retrospect ProjectGets together with other team members and identifies the lessons learntGets together with other team members and identifies the lessons learntGets together with other team members and identifies the lessons learntSo, what best describes a Scrum team? There are many facets to a Scrum team, but the most relatable description would be a highly interconnected and cohesive unit that works together to solve issues. A well-organized Scrum team can raise the ROI of an organization and ensure long term stakeholder commitment.
What Best Describes a Scrum Team?

We are living in an age where speed is the secret ... Read More

Useful links