Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

• Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
• Developers sync up daily so that the plan for next 24-48 hours is effectively done
• Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
• Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

• Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
• Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
• Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
• Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
• Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
• If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
• Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
• Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.

Conclusion

Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

The post Myth – Scrum Master being the Mandatory participant of Daily Scrum appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Sprint Zero seems a good idea

When the team start work the team observes these typical problems

• There is no reasonable Product Backlog from which a Sprint Backlog can be created.
• Designs are not good enough to start
• Architecture decisions are often delayed

Team often struggles to create a usable product increment during the first Sprint. Often then, the teams starts with a Sprint Zero so that a usable product increment may not be expected from the team.

At the outset, it looks to be a great idea – especially those who have come from a waterfall mindset and are used to doing a lot of preparation before beginning a project.

Negative consequences of Sprint Zero

Sprint Zero is often considered an agile-sounding term for pre-Sprint preparation work where no increment of product value is provided at all. In reality, the whole intent of the Sprint is lost. To be a Sprint, something of value must be delivered in a clearly time-boxed fashion.

What could be done instead of Sprint Zero

• In Agile, we believe in just-in-time work. However, in reality this may increase the risk. Hence we should start thinking about the work (which includes designs, architectures, refinement of PB) 2-3 sprints in advance. Not too early, and not too late.
• Weak product management results in this anti-pattern. Agile does not mean that we don’t have planning. There is a lot of planning in agile. However, the planning is done such that the team has enough work for the next 2-3 sprints. Not having decisions ready, not having a product backlog ready often causes the team to resort to this type of anti-pattern.
• Critical Architecture decisions, critical design decisions, critical business decisions need to be identified. They may become show-stoppers later and the team may not have enough work for the next sprint.

The post Sprint Zero – An Anti Pattern appeared first on World Of Agile.

Common Misconceptions and negative implications

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. The negative implication of this practice is that the “Inspect and Adapt” cannot happen. This becomes just disguising the waterfall and calling it Scrum.

Recommendations

• There should only be one Sprint Backlog. This represents the forecast for the current Sprint. At the end of the Sprint, the Sprint Backlog is emptied. All remaining items are taken back to the Product Backlog. All completed and done items are taken into Increment. The reason why this is done this way is to give opportunity to the Product Backlog to be re-ordered if needed.
• It is possible that the Product Backlog item changes the order since there might be change of business priorities. If the Sprint Backlog is baselined for multiple sprints at the start then an important opportunity for inspection and adaptation is lost.
• The discussions in the Sprint Planning result into a new Sprint Backlog based on the business objective to be achieved this Sprint. Even during the sprint, the Sprint Backlog emerges – more details get added and new things get clarified.
• To see how to handle changes in scrum please click here

The post Myth about creating multiple Sprint Backlogs before first sprint starts appeared first on World Of Agile.

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

• Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
• Considerations for changing the Sprint Lengths
• Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
  • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
  • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
  • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
  • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
• Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
  • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
  • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
  • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
  • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
  • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
• DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
  • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
  • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
  • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

The post Myth about baselining the Sprint Lengths at the start of the project and never changing it appeared first on World Of Agile.

Common Misconceptions and negative implications

Most leadership and product owners feel that Developers has to commit to a scope during the Sprint Planning. That is, most leadership try to implement the concept of “baseline scope” for the Sprint.

• By doing this, it prevents opportunities for inspection and adaptation during the sprint.
• Team gets “locked” into delivering baselined scope instead of trying to find out if they are going in the right direction or wrong.
• Critical opportunity to inspect and adapt is then lost and deviation is detected during the Sprint review.
• Then starts the discussions on “change requests”, “sign offs”, “not being able to give scope properly”When the Developers yields to pressure of delivering baselined scope, the team comes under pressure and naturally working hours increase. More dissatisfaction results.

Recommendations

• At the time of Sprint Planning meeting make only a forecast instead of commitment. One should have an openness to change if the need be instead of making the team commit.
• Adapting quickly helps one get more closer to what is required to be done really.
• Once an attitude develops with the team that “we are adaptable” and “not everything needs to be done as per forecast” teams become more receptive to the change.
• Sprint Backlog always evolves – and let it evolve. The whole point why we are doing Scrum is because of the “unknown” nature of the work.
• The reason the teams are reluctant to accept changes in the Sprint Backlog is because they are asked to work late and deliver the commitment and at the same time accept all last-minute changes. One must remember that there is always a cost of the change. However, the cost of the change is taken in terms of a Scope compromise in Scrum. That means if the Sprint backlog changes, something in the Sprint Backlog may have to be pushed to the next sprint or later.
• One must remember that while the Sprint Backlog evolves, does not mean we are random and chaotic in our way of work. We are handling changes. We are not in Chaos. That means, if the changes are big, and big changes are happening frequently then it is time to either look at how we are gathering our requirements or if the Sprint Lengths are to be shortened.
• To see how to handle changes in scrum please click here

The post Myth about Sprint Backlog being a commitment appeared first on World Of Agile.

The Increment is the sum of all Product Backlog Items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done” which means that it should be in a useable condition and meet the Scrum Team’s definition of Done. It must be in a useable condition regardless of whether the Product Owner decides to actually release it.

Potentially Releasable Product Increment

Scrum asks that teams deliver “potentially releasable software” at the end of every sprint. To me, potentially shippable software or potentially releasable product increment is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

Example of Potentially Releasable Product Increment

Let us take a simple real-life example to understand this term. Let us say you are interior-decorating your house. You could do the work in multiple ways:

1. You could change the tiles of the entire house, then fix the paint of the entire house and then you could move-in back into the house
2. You could complete one bedroom, then another, then the kitchen and finally the living room.

In the first example, you thought about the entire product (interior decorated house) as one chunk and thought about it in a traditional way. Let us think if we can deliver this in the second option. The second option gives you a way in which, if required you could get incremental value of the product. Potentially Releasable Product Increment is about getting incremental value for your product. Whether you really move-in after completion of the bedroom (in the above example) is your call, however, you have an option – just in case you want to move in.

Let us see the above Cake piece. I can bet that a child would enjoy the piece of a entire Vertical Slice of cake instead of only icing or only chocolate or only cake. Potentially Shippable Product Increment or Potentially Releasable Product Increment is a vertical slice which gives incremental value to the customer.

The post Product Increment appeared first on World Of Agile.

Sprint Backlog consists of

• Sprint Goal (WHY)
• Product Backlog Items selected for this Sprint which will help meet the Sprint Goal (WHAT)
• Plan to deliver the Product Backlog Items (HOW)

It is common practice that the Sprint Backlog is represented on a task board which provides a constantly visible depiction of the status of the items in the Sprint Backlog. Also included in the Sprint Backlog are any risks associated with the various items. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog.

Once the Sprint Backlog is forecasted (based on metrics such as Velocity), the team should make constant changes to the Sprint Backlog as more is known about the Product Backlog items selected. The changes made to the Sprint Backlog should be such that the changes does not compromise the Sprint Goal selected. If major changes arise during a Sprint, they are added to the overall Product Backlog and included in a future Sprint.

Representations of Sprint Backlog

In its most basic form, a Sprint Backlog is represented as a task board and can be drawn on a whiteboard or even a section of wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.

The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each Sprint to reflect the Sprint Plan.

To see how to handle changes in scrum please click here

For myths around Sprint Backlog, refer to following articles

• Myth about Sprint Backlog being a commitment
• Myth about creating multiple Sprint Backlogs before first sprint starts

The post Sprint Backlog appeared first on World Of Agile.

In archaeology, the term “artifact” refers to an object that was made by a human. The Latin roots of the word artifact roughly translate to “Work of Art.” So, an artifact is something that we make, either a tool that solves a problem, or a work of art that inspires us.

Scrum describes three primary artifacts:

• The Product Backlog
• The Sprint Backlog
• The Product Increment

In this section we will learn about the three artifacts. While Scrum describes only 3 artifacts, please understand that these are the minimum artifacts that Scrum prescribes. You can add any number of artifacts beyond these three to achieve your goals, however, the additional artifacts are not the Scrum artifacts.

The post Scrum Artifacts appeared first on World Of Agile.