Search

Series List

How Not to be Agile – Daily Stand-Up/Scrum

IntroductionHello and welcome to this, the fifth 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.In this article, I will cover some of the misunderstandings and malpractices that I have come across to do with the daily stand-up event; all the Agile frameworks use the term ‘daily stand-up’ for the event except Scrum which calls it a ‘daily Scrum’.As I said before, it is the content and management of the daily stand-up that is important; call the event what you like.I will start with a description of the daily stand-up and then give examples of what can go wrong.Importance of Daily Stand-Up Meetings in ScrumThe concept of a daily stand-up was first introduced to the Agile community by the Scrum framework and has since been adopted by all other Agile frameworks.The idea behind a daily stand-up is to give the whole development team an opportunity to see what has been happening in the development timebox since the previous stand-up, what is planned to be done before the next stand-up and to state any problems that they may be having.The development team uses the daily Scrum stand-up to inspect progress toward meeting the development timebox goal and the likelihood that the development timebox MVP will be met.This is recommended to be done by each team member answering 3 questions:What have I been doing since the last stand-up?What do I plan to do before the next stand-up?What blocks/impediments/issues/problems am I having?Developments over time to the daily Scrum meeting process include:Carrying out the stand-up in front of the Team Board and updating it as necessaryUsing video-conferencing and a shared, electronic Team Board for distributed teamsAdding questions such as:Has anyone given me a requirement change request?Have I learned anything about this product development that I think everyone should know about?Do I have any worries about how the team is progressing?The Scrum Guide states that the daily stand-up should take no more than 15 minutes; the Agile Project Framework suggests that normally the daily Scrum stand-up should not last more than 15 minutes but also suggests that 2 minutes per participant + 2 minutes is a good guide; for a team of 9 members this would equate to 20 minutes.If there are any ‘matters arising’ from the daily stand-up, most teams will delay discussion until after the stand-up is finished and then only those that are needed for the discussion stay behind; the rest go back to work.What the Daily Scrum Meeting is Not?During early Agile transitions it is ‘tempting’ for the management to ‘watch’ the development team closely and the daily stand-up turns into a ‘reporting progress to management’ session.This is NOT what the daily stand-up is for and all attempts to turn it into one must be resisted.An Alternative to Daily Stand-Up processThe Kanban framework and other lean process practitioners realised that the ‘standard’ 3 questions above are not really relevant because people just need to take a look at the Scrum Board (kanban) to see what they did recently and what they will do the next; remember the use of a Team Board is not ‘mandatory’ in most of the Agile frameworks but it would be unusual for a team not to use one, whether a physical board or an electronic one.                                                                     Figure 1 - Physical Team Board Example                                                                                             Figure 2 - Electronic Team Board Example So, here are the questions that a Kanban user answers:What is impeding us?Assuming, that the meetings take place in front of the board, there isn't even a need to discuss what items are impeded (since this will be visible on the board).  Therefore, all there is to focus on, is the possible and the best solutions to the problematic items.What's the flow like?Because Kanban is all about the workflow, what should be discussed at this point are any possible changes that the team can make in order to make the flow even smoother and efficient.  Also, should there be any bottlenecks, the daily stand-up is the right time to work on their best resolution.What can we improve? (how to achieve Kaizen?)This is a question is the means by which the entire team is empowered to strive for constant improvement; by allowing for the change suggestions to come from anyone in the team, there is a big chance of success.Effectively, the Kanban Framework incorporates every day what other frameworks do in the Retrospective.Whatever Agile framework that you use, if you adopt a Kanban style Team Board, you may want to use the Kanban questions during your daily stand-ups.Who Should Attend the Daily Stand-Up?It is important that all of the development team, both full and part-time, and the Agile Project Manager/Scrum Master attend the daily stand-up:The whole development team needs to be there because all team members need to be aware of what is happening in the development timebox, state any problems that they may be having and potentially offer help to other team members who may have problems.The Agile Project Manager/Scrum Master needs to be there as the Risk and Issue Manager to listen to the problems that any team members may have.The daily stand-up should be run by the development team although, in some organisations, the Agile Project Manager/Scrum Master runs the event.Other people outside of the Development Team are ‘welcome’ to attend daily Scrum meeting but are not allowed to speak; they are only there to observe the process.When Should the Daily Stand-Up Take Place?One of the tenets of all Agile frameworks is to have a cadence or ‘heartbeat’; events should be scheduled on the same day, time, and place for the whole product development time.It is strongly recommended that the daily stand-up should be scheduled to take place in the same place at the same time every working day.Case Study 1:In several organisations that I have coached in, when I arrived, the daily stand-ups were taking upwards of 30 mins; this was because:There was a detailed discussion between 1 or 2 team members about some topic or otherOne or two members were overly verbose in their explanation of what they had done and what they were going to doIn all cases, the majority of other team members were not interested in the details of the conversations or another’s work; some used the ‘wasting my time’ reason to avoid attending the daily-stand-ups.In one organisation, I was teaching an Agile class and on day 2, 3 delegates turned up 1 hour late for a 9am start.  I asked, politely, if they had a problem attending on time and was told that they had to attend their team’s daily stand-up; a laudable reason.  When I asked what time their team’s daily stand-up started I was told 9am; the event had taken 50 minutes!What was worse was that one of the delegates was supposed to be the Scrum Master for the development!Lessons:Don’t start Agile product Development without the Agile PM/Scrum Master having had at least 2 days of training on the Agile framework that they should be usingWhoever is running the daily stand-up, do not allow:Detailed explanations of work done or planned to be doneDetailed discussions of points between 1 or 2 team membersMatters will arise during the daily stand-up but discussion of these must be held over until the daily stand-up has finishedIf a team member says they have an impediment and it can be solved in about 15 seconds, then that is OK; for example, a team member may say:“ I cannot get hold of person XYZ to get the information I need”Another team member may have had the same problem in the past and may say something like:“He/she never answers the phone during the morning; call him/her after 2 pm”Case Study 2:For one engagement that I was working on, the Development Team was dispersed in 5 locations in 3 different time zones.  I noticed that one team member in another location never attended the daily stand-up; the Scrum Master obtained the answer to the 3 questions later in the day over the phone.I asked the Scrum Master why this was so and he told me that the person was in a time zone 1 hour behind the main team and had travelling difficulties getting into work for the daily stand-up time.I asked when the team member could ‘guarantee’ getting into work and would there be any problem moving the daily stand-up time.  It transpired that the time of the daily stand-up could be moved to suit the team member without inconveniencing any of the other team members.LessonsThe time for the daily stand-up should be set when all development team members have a good chance of attending; this is important for geographically dispersed teams.The Scrum Master gathering daily stand-up information after the event wastes his/her time and the rest of the team miss the opportunity to have all the information that they needCase Study 3: There have been 3 occasions when time zones  played an important part in choosing when the daily stand-up should be held:The main team was in Tokyo, there was a sub-team in Beijing, the ‘customer’ was in San Diego and management was in Helsinki; this was the first Agile product development for this team although other teams in the organization had transitioned.Although it is not normal for the customer or management to attend the daily stand-up, in this case, both the customer and management wanted to attend to make sure that the team were ‘on the right track’; the fact that I had trained the main team hadn’t given the management sufficient confidence!But the time zone differences made it difficult to choose an appropriate team for all attendees.Because there were only 1 customer and 1 manager who wanted to join the stand-up, it was decided to hold the stand-up at 1pm Tokyo time to inconvenience the main and sub-teams the least; for the customer in San Diego it was 11pm and for the manager in Helsinki it was 5am.We ran like this for 1 week after which both the customer and manager decided that they were happy with the way the main team and sub-team were operating.The Development Team were in Cebu, Philippines, and the Product Owner was in Duluth, USA; the Product Owner wanted a daily update on how the requirements were being implemented.There was no overlap in the work times of the different time zones so it was decided that the Scrum Master would start work at 1pm Cebu time, the daily stand-up would be run at 2pm Cebu time and the Scrum Master would update the Product Owner at 9pm Cebu time, 8am Duluth time.The majority of the team were in Dundee, Scotland with a few team members in Hyderabad, India.In this case, there was a 3.5 hour overlap in the work times of the different time zones so it was decided to run the daily stand-up at 10am Dundee time and 3:30pm Hyderabad time.Lessons:Although this Case Study does not demonstrate anti-Agile behaviour, it is worth noting the following lessons:When deciding a time to run the daily stand-up, the time should be set to inconvenience the development team members as little as possible; other people must choose whether their attendance during ‘unsocial hours’ is worth it to themselves.The Agile PM/Scrum Master does not have to work the same hours as the rest of the development team in the same time zone; it does depend on whether the Agile PM/Scrum Master is prepared to work ‘unsocial hours’.Where work times overlap across time zones, ensure that the time to run the daily stand-up is within the work times of all time zones. Case Study 4:I was coaching a team that was in the early stages of an Agile transformation and the team members had picked up the basics well; the daily stand-ups were running well with some good banter and team member help being offered freely.During one stand-up, I noticed a marked lack of relaxation amongst the team members when speaking and their heads were down most of the time.I asked the Scrum Master if he knew the reason for the change of atmosphere and she said that she had expected something like it but not quite so marked.There had been a manager attending for the first time; this manager had a reputation for being a bit ‘old school’; “do as I say and no arguments”.After confirming with the team members that they had felt intimidated, I researched the manager and discovered that he headed a department that was just starting to try Agile; the manager had attended the stand-up just to see how it worked and had had no intention of ‘interfering’ or making any opinions about the team members.I asked if he would like me to coach ‘his’ team through their early Agile events; he accepted and I invited him to attend all the events as an observer.After each event, I mentored the manager about his opinion of what went on.  He had a few questions about ‘why this’ and ‘why that’ and I was able to answer his questions to his satisfaction.I asked ‘his’ team members what they thought of having the manager at their events and they said that they had had some trepidation at first but after they could see that he had been there to learn and had not lived up to his previous reputation, they became quite comfortable with the manager’s presence.I told the members of the original team of this apparent change to the manager’s ‘personality and asked if he could attend the next daily stand-up; they agreed and the next stand-up with the manager present went as ‘normal’.Lessons:If there is a change of demeanour of any individual or several team members, investigate the reason; it is most probably an impediment to smooth team running.The Scrum Master could have just asked the manager not to attend anymore but given the manager’s perceived reputation, that would have taxed the Scrum Master’s diplomacy skills.By engaging with the manager, it was possible to shift his ‘old school’ manner to one that understood Agile and could cooperatively support it.ConclusionThe ‘mechanics’ of the daily stand-up are relatively straightforward if the rules of the Daily Scrum are followed strictly in a daily routine. Collated below are the best practices while implementing daily Scrum:All development team members must attend, both full and part-time members.The time and place for the daily stand-up should be chosen to give the least inconvenience to the development team members.Geographically dispersed teams can run daily stand-ups using video-conferencing and shared desktop facilities.The questions to be answered by development team members should be adjusted to suit the type of Team Board being used.Non-development team members are welcome to attend daily stand-ups but are not allowed to speak.If the attendance at a daily stand-up of a non-development team member is considered to ‘intimidate’ one or more team members, this is an impediment and the resolution must be sought.
Rated 4.5/5 based on 11 customer reviews
How Not to be Agile – Daily Stand-Up/Scrum 3661
  • by Steve Ash
  • 05th Nov, 2018
  • Last updated on 06th Mar, 2019
  • 18 mins read
How Not to be Agile – Daily Stand-Up/Scrum

Introduction

Hello and welcome to this, the fifth 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.

In this article, I will cover some of the misunderstandings and malpractices that I have come across to do with the daily stand-up event; all the Agile frameworks use the term ‘daily stand-up’ for the event except Scrum which calls it a ‘daily Scrum’.

As I said before, it is the content and management of the daily stand-up that is important; call the event what you like.

I will start with a description of the daily stand-up and then give examples of what can go wrong.

Importance of Daily Stand-Up Meetings in Scrum

Daily Stand-Up Meetings in Scrum

The concept of a daily stand-up was first introduced to the Agile community by the Scrum framework and has since been adopted by all other Agile frameworks.

The idea behind a daily stand-up is to give the whole development team an opportunity to see what has been happening in the development timebox since the previous stand-up, what is planned to be done before the next stand-up and to state any problems that they may be having.

The development team uses the daily Scrum stand-up to inspect progress toward meeting the development timebox goal and the likelihood that the development timebox MVP will be met.

This is recommended to be done by each team member answering 3 questions:

Daily Stand-Up Meetings in Scrum

  1. What have I been doing since the last stand-up?
  2. What do I plan to do before the next stand-up?
  3. What blocks/impediments/issues/problems am I having?

Developments over time to the daily Scrum meeting process include:

  • Carrying out the stand-up in front of the Team Board and updating it as necessary
  • Using video-conferencing and a shared, electronic Team Board for distributed teams
  • Adding questions such as:

    • Has anyone given me a requirement change request?
    • Have I learned anything about this product development that I think everyone should know about?
    • Do I have any worries about how the team is progressing?

The Scrum Guide states that the daily stand-up should take no more than 15 minutes; the Agile Project Framework suggests that normally the daily Scrum stand-up should not last more than 15 minutes but also suggests that 2 minutes per participant + 2 minutes is a good guide; for a team of 9 members this would equate to 20 minutes.

If there are any ‘matters arising’ from the daily stand-up, most teams will delay discussion until after the stand-up is finished and then only those that are needed for the discussion stay behind; the rest go back to work.

What the Daily Scrum Meeting is Not?

During early Agile transitions it is ‘tempting’ for the management to ‘watch’ the development team closely and the daily stand-up turns into a ‘reporting progress to management’ session.

This is NOT what the daily stand-up is for and all attempts to turn it into one must be resisted.

An Alternative to Daily Stand-Up process

The Kanban framework and other lean process practitioners realised that the ‘standard’ 3 questions above are not really relevant because people just need to take a look at the Scrum Board (kanban) to see what they did recently and what they will do the next; remember the use of a Team Board is not ‘mandatory’ in most of the Agile frameworks but it would be unusual for a team not to use one, whether a physical board or an electronic one.

 Physical Team Board Example                                                                      Figure 1 - Physical Team Board Example 

Electronic Team Board Example                                                                                             Figure 2 - Electronic Team Board Example 

So, here are the questions that a Kanban user answers:

  • What is impeding us?

Assuming, that the meetings take place in front of the board, there isn't even a need to discuss what items are impeded (since this will be visible on the board).  Therefore, all there is to focus on, is the possible and the best solutions to the problematic items.

  • What's the flow like?

Because Kanban is all about the workflow, what should be discussed at this point are any possible changes that the team can make in order to make the flow even smoother and efficient.  Also, should there be any bottlenecks, the daily stand-up is the right time to work on their best resolution.

  • What can we improve? (how to achieve Kaizen?)

This is a question is the means by which the entire team is empowered to strive for constant improvement; by allowing for the change suggestions to come from anyone in the team, there is a big chance of success.

Effectively, the Kanban Framework incorporates every day what other frameworks do in the Retrospective.

Whatever Agile framework that you use, if you adopt a Kanban style Team Board, you may want to use the Kanban questions during your daily stand-ups.

Who Should Attend the Daily Stand-Up?

It is important that all of the development team, both full and part-time, and the Agile Project Manager/Scrum Master attend the daily stand-up:

  • The whole development team needs to be there because all team members need to be aware of what is happening in the development timebox, state any problems that they may be having and potentially offer help to other team members who may have problems.
  • The Agile Project Manager/Scrum Master needs to be there as the Risk and Issue Manager to listen to the problems that any team members may have.

The daily stand-up should be run by the development team although, in some organisations, the Agile Project Manager/Scrum Master runs the event.

Other people outside of the Development Team are ‘welcome’ to attend daily Scrum meeting but are not allowed to speak; they are only there to observe the process.

When Should the Daily Stand-Up Take Place?

One of the tenets of all Agile frameworks is to have a cadence or ‘heartbeat’; events should be scheduled on the same day, time, and place for the whole product development time.

It is strongly recommended that the daily stand-up should be scheduled to take place in the same place at the same time every working day.

Case Study 1:

In several organisations that I have coached in, when I arrived, the daily stand-ups were taking upwards of 30 mins; this was because:

  • There was a detailed discussion between 1 or 2 team members about some topic or other
  • One or two members were overly verbose in their explanation of what they had done and what they were going to do

In all cases, the majority of other team members were not interested in the details of the conversations or another’s work; some used the ‘wasting my time’ reason to avoid attending the daily-stand-ups.

In one organisation, I was teaching an Agile class and on day 2, 3 delegates turned up 1 hour late for a 9am start.  I asked, politely, if they had a problem attending on time and was told that they had to attend their team’s daily stand-up; a laudable reason.  When I asked what time their team’s daily stand-up started I was told 9am; the event had taken 50 minutes!

What was worse was that one of the delegates was supposed to be the Scrum Master for the development!

Lessons:

  1. Don’t start Agile product Development without the Agile PM/Scrum Master having had at least 2 days of training on the Agile framework that they should be using
  2. Whoever is running the daily stand-up, do not allow:
  • Detailed explanations of work done or planned to be done
  • Detailed discussions of points between 1 or 2 team members
  1. Matters will arise during the daily stand-up but discussion of these must be held over until the daily stand-up has finished

If a team member says they have an impediment and it can be solved in about 15 seconds, then that is OK; for example, a team member may say:

“ I cannot get hold of person XYZ to get the information I need”

Another team member may have had the same problem in the past and may say something like:

“He/she never answers the phone during the morning; call him/her after 2 pm”

Case Study 2:

For one engagement that I was working on, the Development Team was dispersed in 5 locations in 3 different time zones.  I noticed that one team member in another location never attended the daily stand-up; the Scrum Master obtained the answer to the 3 questions later in the day over the phone.

I asked the Scrum Master why this was so and he told me that the person was in a time zone 1 hour behind the main team and had travelling difficulties getting into work for the daily stand-up time.

I asked when the team member could ‘guarantee’ getting into work and would there be any problem moving the daily stand-up time.  It transpired that the time of the daily stand-up could be moved to suit the team member without inconveniencing any of the other team members.

Lessons

  1. The time for the daily stand-up should be set when all development team members have a good chance of attending; this is important for geographically dispersed teams.
  2. The Scrum Master gathering daily stand-up information after the event wastes his/her time and the rest of the team miss the opportunity to have all the information that they need

Case Study 3: 

There have been 3 occasions when time zones  played an important part in choosing when the daily stand-up should be held:

  1. The main team was in Tokyo, there was a sub-team in Beijing, the ‘customer’ was in San Diego and management was in Helsinki; this was the first Agile product development for this team although other teams in the organization had transitioned.

Although it is not normal for the customer or management to attend the daily stand-up, in this case, both the customer and management wanted to attend to make sure that the team were ‘on the right track’; the fact that I had trained the main team hadn’t given the management sufficient confidence!

But the time zone differences made it difficult to choose an appropriate team for all attendees.

Because there were only 1 customer and 1 manager who wanted to join the stand-up, it was decided to hold the stand-up at 1pm Tokyo time to inconvenience the main and sub-teams the least; for the customer in San Diego it was 11pm and for the manager in Helsinki it was 5am.

We ran like this for 1 week after which both the customer and manager decided that they were happy with the way the main team and sub-team were operating.

  1. The Development Team were in Cebu, Philippines, and the Product Owner was in Duluth, USA; the Product Owner wanted a daily update on how the requirements were being implemented.

There was no overlap in the work times of the different time zones so it was decided that the Scrum Master would start work at 1pm Cebu time, the daily stand-up would be run at 2pm Cebu time and the Scrum Master would update the Product Owner at 9pm Cebu time, 8am Duluth time.

  1. The majority of the team were in Dundee, Scotland with a few team members in Hyderabad, India.

In this case, there was a 3.5 hour overlap in the work times of the different time zones so it was decided to run the daily stand-up at 10am Dundee time and 3:30pm Hyderabad time.

Lessons:

Although this Case Study does not demonstrate anti-Agile behaviour, it is worth noting the following lessons:

  1. When deciding a time to run the daily stand-up, the time should be set to inconvenience the development team members as little as possible; other people must choose whether their attendance during ‘unsocial hours’ is worth it to themselves.
  2. The Agile PM/Scrum Master does not have to work the same hours as the rest of the development team in the same time zone; it does depend on whether the Agile PM/Scrum Master is prepared to work ‘unsocial hours’.
  3. Where work times overlap across time zones, ensure that the time to run the daily stand-up is within the work times of all time zones. 

Case Study 4:

I was coaching a team that was in the early stages of an Agile transformation and the team members had picked up the basics well; the daily stand-ups were running well with some good banter and team member help being offered freely.

During one stand-up, I noticed a marked lack of relaxation amongst the team members when speaking and their heads were down most of the time.

I asked the Scrum Master if he knew the reason for the change of atmosphere and she said that she had expected something like it but not quite so marked.

There had been a manager attending for the first time; this manager had a reputation for being a bit ‘old school’; “do as I say and no arguments”.

After confirming with the team members that they had felt intimidated, I researched the manager and discovered that he headed a department that was just starting to try Agile; the manager had attended the stand-up just to see how it worked and had had no intention of ‘interfering’ or making any opinions about the team members.

I asked if he would like me to coach ‘his’ team through their early Agile events; he accepted and I invited him to attend all the events as an observer.

After each event, I mentored the manager about his opinion of what went on.  He had a few questions about ‘why this’ and ‘why that’ and I was able to answer his questions to his satisfaction.

I asked ‘his’ team members what they thought of having the manager at their events and they said that they had had some trepidation at first but after they could see that he had been there to learn and had not lived up to his previous reputation, they became quite comfortable with the manager’s presence.

I told the members of the original team of this apparent change to the manager’s ‘personality and asked if he could attend the next daily stand-up; they agreed and the next stand-up with the manager present went as ‘normal’.

Lessons:

  1. If there is a change of demeanour of any individual or several team members, investigate the reason; it is most probably an impediment to smooth team running.
  2. The Scrum Master could have just asked the manager not to attend anymore but given the manager’s perceived reputation, that would have taxed the Scrum Master’s diplomacy skills.
  3. By engaging with the manager, it was possible to shift his ‘old school’ manner to one that understood Agile and could cooperatively support it.

Conclusion

The ‘mechanics’ of the daily stand-up are relatively straightforward if the rules of the Daily Scrum are followed strictly in a daily routine. Collated below are the best practices while implementing daily Scrum:

  • All development team members must attend, both full and part-time members.
  • The time and place for the daily stand-up should be chosen to give the least inconvenience to the development team members.
  • Geographically dispersed teams can run daily stand-ups using video-conferencing and shared desktop facilities.
  • The questions to be answered by development team members should be adjusted to suit the type of Team Board being used.
  • Non-development team members are welcome to attend daily stand-ups but are not allowed to speak.
  • If the attendance at a daily stand-up of a non-development team member is considered to ‘intimidate’ one or more team members, this is an impediment and the resolution must be sought.
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 *

Suggested Blogs

Scrum Epic: What Is It And How To Create The Best Epics In Agile?

Scrum has been a buzzword since a decade now, and why not, it has so many success stories, hey, I am not talking about the stories which mean requirements in Scrum but the actual stories of teams and the organizations practicing Scrum. Looks like, I just gave the hint of what I would be covering in my article today.Yes, we will be talking about the requirements and how are they handled in Scrum. We will be talking about the Epic, so far, we have known Epic as a long narrative about the heroes of great historical or legendary significance performing courageous deeds but here we will touch upon a different side. Believe me, we are now going to talk about the EPICs in Scrum!What is an Epic in Agile?In simple terms, Scrum EPIC in Agile Methodology is a big chunk of work which can be divided into smaller user stories. An epic can be spread across sprints and even across agile teams. An epic can be a high-level description of what the client wants, and accordingly, it has some value attached to it. As we mentioned, an epic is a high-level requirement, hence its scope can change over the course of time.“Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break down the work into shippable pieces so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down while continuing to work towards a bigger goal.”- Atlassian                                                                                                                                                                                                                                               To explain it better, I would prefer taking a life example, let’s say, throwing a New Year party at your place can be an epic requirement for you. To do so, you’ll need to organize your effort: from the biggest objectives down to the smallest details. You should be able to respond to change, report your progress, and stick to a plan. Once you are aware of the epic, you can drill it down to create smaller tasks like creating a guest list, deciding on the menu, shopping for the grocery, decoration at home, shopping for the new year, etc.Let’s see how we can create an Epic also called Scrum Epic User Story – In today’s era, almost all the tools that the team use have the capability to create an epic, it is up to the product and the team, which type of Epic they want.Some Epics cater to the reporting needs of management. Some Epics are created with a timeframe in mind, it should not be too long and too short, i.e. it should not take more than a couple of weeks to finish. But the widely used way is Storytelling.So, what is StorytellingStorytelling is a tool which helps you visualize the flow of events and how they corroborate back up to the Epic. If you feel, your working pattern does not sit in any of the mentioned ways, create your own. Just remember, Agile is never prescriptive, it shows you the path and how you want to go over it, it’s your choice!Coming back to our example, let us try to break it down into some doable components. It is really important to create chunks out of the epic so that the team can pick those up and deliver in a sprint time. You can compare this activity to art which requires precision in terms of size, priority, minimally interdependent etc. There are some pre-set ways of doing it, like:Workflow break downHere in our example, we talked about a project where we have a New Year party, let’s see how we can break it down in terms of workflow – Shopping can be a workflow where you need to get the items from outside. Another workflow can be cooking the food for the guests, same way we can have decorating the house as another workflow. See how simple it gets to understand once you start connecting it with our lives! This also helps the product owner to easily prioritize the work, in our case, the Product Owner can be the host of the party. Some steps in the workflow may not be important right now and can be moved to later stages. Perhaps baking the cake takes on the priority as it takes time to cool down but the same can be done later as well.Role-based breakdownWe can also break an epic as per the role or the persona, there can be different roles in your product or a project, here we have role of a ‘host’, ‘guest’ or you can have a role as a ‘cook’, you can even add the roles as per your product. In a role-based breakdown we talk in terms of that particular persona, example, for a host, ‘Driving a successful party’ can be one, for a guest, it can be, ‘Looking for some fun games at the party’.Break Down around the timelineSome of the epics can be broken down according to the time it will take to complete. The team usually divides the work which can be accomplished in a sprint time. They take up the whole thing, break it into pieces and fit the pieces in different sprints as per the dependency and priority. As I have already mentioned, the breaking down requires consideration into several areas such as size, priority, interdependency etc. Thus, there are two approaches to dividing – Horizontal and Vertical. It is like cutting the cake, if you cut it horizontally, you will get a single layer but if you take a vertical approach, you will get to have a bit of all the layers. Understanding the basic differences between Epic, Story, and TaskWe have been talking a lot about Epic and its breakdown, now let’s capture how it actually disintegrates further. We had an Epic “New Year Party”, this was a big chunk of work to be accomplished, we learned about the techniques to break it down. The result of the breakdown is termed Stories, which can be accomplished in a sprint time. The stories are further broken down into chunks called ‘Tasks’, the team pulls up the tasks and completes them, once all the tasks are completed, the story is marked as Completed. The below figure explains Scrum Epic Vs User Story:Thus,Epic - A requirement that is just too big to deliver in a single sprint. Epics need to be broken into smaller deliverables (stories).Story - A requirement that the business wants. It is something that is deliverable within a single sprint.Tasks - The essentials of a story, these are the milestones to take the story to ‘Done’.Anything that we cannot measure will not yield many results, we have been hearing this for a long time. It does apply here as well. We can use burndown charts to measure how much work has been accomplished in an Epic. This also helps in predicting if the team is on track with the commitments. By keeping a watch on the Burndown chart, it becomes easy to manage the progress and the blockers (if any) that the team is facing. This not only provides transparency to the system but it also helps in building the trust for the team and the clients.How to identify Epics in AgileEpic is something which is a fairly large chunk of work and cannot be completed at one go. It is something which requires discussion and brainstorming so that it can be broken down further into smaller chunks. At the epic level, we give rough estimates which can be in the form of T-shirt sizes, swags, points or any other method the team is comfortable with. The team can track the progress in an epic through the Burndown chart which represents the progress and also reflects if there are any blockers. Benefits of EpicsEpics help in understanding the high-level requirement from the stakeholder and what exactly is the need.It also helps in defining the scope of work which is in agreement with the client. Epics articulate efficiently about final output of user needs. Epics help to track bigger thoughts in a product backlog without the need to overwhelm it with multiple things. They allow establishing a hierarchy for the backlog items where the epic represents the original idea often closely related to a particular outcome.It also helps in estimating how much time it will take to deliver. Epics are time and again used as placeholders for new views that have not been thought out completely, or whose full expansion has been postponed till essentially desirable.Epics are then evolved into split into multiple user stories that help Agile development teams effectively manage and groom their product backlog.Common Pitfalls in EpicThough there are many positive aspects of using the epics in backlog management a coin always has two sides, it has its pitfalls too! Sometimes, the teams can create confusions around the end deliverable from the epic by just viewing them as more than just large user stories. This is deceptive when the team creates multifaceted tools to distinguish between epics and user stories as well as creates far-reaching tools for chasing epics separately from other backlog items.The teams may also try to estimate the epics at a very high level though they might not have a clear picture of what is to be done. This increases the chances of ambiguity and it is very likely that the estimates will not be of any use as it will not serve any purpose in reporting.Finally, here we are, with the discussions around the Epics and how we can break it down. There is no set way to work on the epic, it about what approach suits your needs. Again, it is all about the mindset and way we deal with the backlog. Epics are always fascinating to work with!
Rated 4.5/5 based on 12 customer reviews
9932
Scrum Epic: What Is It And How To Create The Best ...

Scrum has been a buzzword since a decade now, and ... Read More

All You Need to Know About Leading Safe 4.5® Certification With Knowledgehut

Agile is a project management process which encourages self-organization, accountability, and teamwork. This methodology progresses a moderate project management process by reducing the time required for review and adaptation. SAFe combines the power of Agile with Lean product development and systems thinking. It integrates delivery, collaboration, and alignment for multiple Agile teams and provides significant improvements to business agility, including quality, productivity, employee engagement, customer satisfaction, time-to-market, and more. The new version i.e SAFe® 4.5 was released on June 22, 2017. This advanced version speeds up the delivery process of products and services and also offers a 360-degree build-measure-learn feedback cycle. With four major updates, SAFe has grown faster with the market since the initial release in 2011 and keeps on being a work in process. SAFe 4 Agilist certification helps you to build a strong foundation on Agile practices, standards, and applications required to enhance the  probability of the project's overall success. You might be searching for the best institute to take the course and might be thinking why only KnowledgeHut and why not others? Here we answer all your queries about Leading SAFe 4.5 Certification with KnowledgeHut. Looking for a quick overview of #SAFe? Check out our most popular download: https://t.co/Iw7rVXSK6U pic.twitter.com/oPEExo8mUY — Dean Leffingwell (@Deanleffingwell) October 31, 2017 Who is the certifying agency? SAFe® Enterprise or the Scaled Agile Framework is the provider of this SAFe® 4 Agilist Certification. KnowledgeHut offers this course by professional trainers with years of industry experience.     SAFe® Agilist certification exam cost?   The exam cost for the first attempt is included in the course fee if the exam is taken within 30 days of course completion. Also, the candidate can retake the exam if not cleared in the first attempt and each retake attempt charges $50. Who will benefit from leading SAFe® 4.5 course? The following individuals will benefit from this course: Leaders and Executives, Directors, Managers, CIOs, and VPs Enterprise, System, and Solution Architects QA, Development, and Infrastructure Management Project and Program Managers PMO, Portfolio Managers, and Process Leads Product and Product Line Management Is it mandatory to attend the course or can a person just take the exam directly? Yes, candidates should have completed the 2 days’ Leading SAFe® 4.5 certification training course to take the exam. After successful completion, of course, your trainer registers you to Scaled Academy and after this registration, you will receive an e-mail that includes an exam link. Thereafter, you will have 30-days to take the test.  What do attendees get from the course? The course registration includes: SAFe 4 Agilist PDF certificate SAFe 4 Agilist digital badge to promote your online accomplishment  Comprehensive courseware materials by Scaled Agile Institute 1-year membership with Scaled Agile Access to members-only resources such as advance notice of upcoming SAFe products, guidance presentations, and webinars 16 SEUs and 16 PDUs 1 free attempt of the exam as the course fee includes the exam fee Can I cancel my enrollment? Do I get a refund? Your amount will be refunded in full only if the registration is cancelled within 48 hours and the refunds will be processed within 30 days of the request. For more details, check our refund policy. Note: Due to transactional costs that are applicable while refunding, all cancellations will cause a 5% deduction in the refunded amount. What topics are covered? The topics covered in our 2-day course are: Introducing the SAFe (Scaled Agile Framework) Embracing a Lean-Agile Mindset Experiencing PI (Program Increment) planning Understanding SAFe Principles Implementing an Agile Release Train Leading the Lean-Agile Enterprise Exploring, Executing, and Releasing Value Building an Agile Portfolio and Empowering a Lean Portfolio Prerequisites for SAFe® 4.5 Certification? Anyone regardless of experience can attend the course. But the following knowledge and skills are highly recommended for those who really want to take the SAFe® 4 Agilist certification exam: 5 plus years of experience in business analysis, testing, product or project management, and software development Good experience in Scrum What will I learn from the course? On completion of the course you will be able to: Apply SAFe to scale Lean and Agile development in your organization Identify and apply a Lean-Agile Mindset and principles Empower with a Lean Portfolio Improve your Lean-Agile leadership skills Continuously explore, integrate, deploy, and release value Coordinate the development of large value streams Support a Lean-Agile transformation in your organization How can I apply? Follow the below steps to apply for Leading SAFe® 4.5 certification exam- Step  1: Take the 2-day Leading SAFe®4.5 course Step 2: Your trainer will send all your details to Scaled Agile after successful completion of course. Now, the Scaled Agile Academy will send you two emails: a Welcome Letter and a Learning Plan Assignment. The Learning Plan Assignment e-mail includes information about the exam. Step  3: Take the online SAFe® 4 Agilist certification exam. Step 4: Once the test is completed with the minimum passing score, Scaled Academy will update your profile to disclose the certification. Step 5: You will receive an email including official notification from Scaled Academy which allows you to the member area and helps you to make your profile public within the Scaled Agile Community. 1-year membership with Scaled Agile will be provided as well. Why KnowledgeHut for Leading SAFe® 4.5? KnowledgeHut is a silver training partner of Scaled Agile Inc (SAI) and offers world-class learning to its students with excellence and provides in-depth knowledge required to become a successful world-class professional. KnowledgeHut also offers: Free materials from Scaled Agile Framework. Tricks and tips from our professional Certified Leading SAFe experts who have years of experience in implementing it in a variety of environments. 1-year membership with Scaled Agile included in the course fee. We hope this article cleared all your queries related to SAFe® 4 Agilist certification. Connect with us to know more about the Leading SAFe® 4.5 course.t                               Training Cost                               India        USA               LVC                5500                                                499                                  E-Learning                665                   5165 Exam cost                151                   612
Rated 4.5/5 based on 14 customer reviews
8967
All You Need to Know About Leading Safe 4.5® Cert...

Agile is a project management process which encour... Read More

CSPO Vs PSPO: Deciding Between the Two Scrum Certifications

A product owner is a leader responsible for maximizing the value of the products created by a scrum development team.Both CSPO and PSPO relate to the expertise of a product owner in Scrum framework.As Mike Cohn puts it:“The Scrum product owner is typically a project's key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.”The expertise of product owner is centered around the following:It’s about the productIt’s about understanding product benefitsIt’s about customer experienceIt’s about design thinkingIt’s about collaborationCSPO and PSPO both relate to product ownership which in turn requires business acumen and competency on product vision and roadmap aspects.Both CSPO and PSPO courses offer a learning of wide array of principles, rules, practices, techniques and practical tools that help product owners become effective and successful.As Scrum.org puts it:“Product ownership is about more than mechanics: it’s about taking accountability and focusing on value in everything you do. The role of a product owner is to identify, measure, and maximize value throughout your entire product lifecycle.”If you’re someone who is comfortable with the "business side" of projects, you are probably the right person to aim for a Certified Scrum Product Owner® certification.-Scrum AllianceWhat is CSPO?As defined by the Scrum Alliance, a Certified Scrum Product Owner (CSPO) is someone who has been taught by a Certified Scrum Trainer about the Scrum terminology, practices, and principles that will enable them to fulfill the role of Scrum Product Owner.What is PSPO?PSPO stands for Professional Scrum Product Owner, a course and certification offered by Scrum.org. The Scrum.org mission is “To Improve the profession of Software Development”.Differences between CSPO and PSPOCSPO is an abbreviation which stands for Certified Scrum Product Owner. This is a certification offered by the Scrum Alliance, specifically for the Product Owner role.PSPO is an abbreviation which stands for Profession Scrum Product Owner. This is a certification offered by scrum.org, specifically for the Product Owner role.In my opinion, both certifications are equivalent and define a high-quality standard. There’s a difference in the way of obtaining certifications and how to maintain this.Certifications issued by Scrum Alliance are obtained by taking an online exam after mandatory attending a 2-day training given by a Certified Scrum Trainer.Certifications issued by scrum.org are obtained by taking an online exam without the prerequisite of attending a training. Certifications issued by scrum.org do not expire. Of course, to test and validate your knowledge, having a decent understanding of the product owner role is mandatory, therefore preparation and study are key. Participating in a training to learn, and to experience what Scrum is about, is always highly recommended.While it is quite easy for the people who are very involved in the Agile community to identify the most recognized certifications, but it is not a simple task for those who just arrived at the Agile world.Through this blog, I will provide you a short overview of the differences between CSPO and PSPO credentials to help you in making an informed decision.Note: Please note that these reflect my personal views only.The CSPO workshop is usually informative about Scrum and Agile although the quality may be variable and depends very much on the specific instructor and the materials they provide.The basic Comparison of CSPO and PSPOCSPOPSPOCSPO is offered through Scrum AlliancePSPO is offered through scrum.org CSPO has continuing education credit requirements every three years and is renewable. PSPO never has to be renewed Accreditation BodyThe accreditation body of the CSPO and PSPO certifications are as follows:PSPO - Scrum.orgCSPO - Scrum AllianceRenewal of CSPO and PSPO CertificationsPSPO - once earned, credential does not expire and does not require renewal.CSPO - once earned, credential valid for two years. Starting Feb 2019, renewal would require 20 Scrum educational units(earned in last 2 years only) and a renewal fee of USD 100 PricePSPO - 200 USD for certification license only. Attending the workshop could cost around 500 USD.CSPO - 500 USD. The cost varies based on the location from which you attend the workshop.Need of Course PSPO - No need to take up the course.CSPO - To earn CSPO certificate, you must attend 2 days CSPO classroom training from  a Certified Scrum Trainer (CST) from Scrum Alliance.After Exam CertificationOnce you pass the PSPO exam, you will get industry-recognized "PSPO I" certification, along with a PSPO I logo that you can use to identify your achievement. Similarly, on clearing the CSPO certification exam, you will get a certificate from Scrum AlliancePassing ScorePSPO - 85%CSPO - None. Activities to be completed to achieve the credential is at trainer discretion. Time limit: PSPO - 60 minutesCSPO - NoneNumber of Questions: PSPO - 80CSPO - NoneFormat: PSPO - Multiple Choice, Multiple Answers and True/FalseCSPO - NoneLanguage: PSPO - EnglishCSPO - NoneDifficulty levelPSPO - IntermediateCSPO - NonePSPO has subsequent complexity levels in the form of PSPO I, II, IIICSPO has subsequent complexity level in the form of A-CSPO. Password Expiration DatePSPO - When you purchase a password, it is set up in Scrum.org system and emailed to you within one business day. All Students completing a PSPO course are emailed a password upon completion of the course (typically within 3-5 business days). No expiration date for passwordsCSPO - Depends on the online workflow set up by the Certified Scrum TrainerMembershipPSPO - Membership of Scrum.org and the membership does not expireCSPO - 2 Year Membership with Scrum Alliance. You are eligible to join local user groups and social networks, enjoy discounts on global events, search for careers on our online job board, and more.Other benefitsPSPO:  Once you get certified, your name will be listed on Scrum.org.CSPO: Once you receive the credential, your name is listed on Scrum Alliance portal.The verdict:The main aim of the CSPO certification is to understand the working of Scrum and the role of the Product Owner playing in a Scrum team. While the objective of the Professional Scrum Product Owner (PSPO) certification is to develop a solid understanding of the Product Owner to maximize the value of the software products and systems.PSPO has a level of difficulty associated with it. The things which I like about PSPO certification is that the certification does not mandatorily requires you to attend an in-person workshop. You can prepare all on your own and directly proceed to the examination. Also, PSPO has a lifetime validity once acquired, no need to renew the certificate. To evaluate the value of any certification we need to consider:How knowledge or competency in a subject is evaluated and how rigorous is the assessment process. The cost involved with attaining the certification and the validity also play an important role.Before reaching any conclusion on which Scrum certification is better-CSPO or PSPO to choose, you must have heard somewhere that simply earning a skill is not enough, you need to prove your potentiality to the employers. Certification is just a way to reach to the recruiters. To get noticed by the potential employer, start looking for the various certifications options available to steer your success. 
Rated 4.5/5 based on 2 customer reviews
5170
CSPO Vs PSPO: Deciding Between the Two Scrum Certi...

A product owner is a leader responsible for maximi... Read More