scrum Archives - Snehamayee's World Of Agile

Myth about Scrum only being useful for small projects

It is a common mis-conception that Scrum is only useful for small projects.

The fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution. Read more to find out more

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.

Conclusion

The size of the project has nothing to do with the use of Scrum or not.

Scrum is based on Empirical Process Control Theory. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-only-being-useful-for-small-projects/

Myth about creating multiple Sprint Backlogs before first sprint starts

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. Is this rught way – read on to discover

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.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-creating-multiple-sprint-backlogs-before-first-sprint-starts/

Some Ideas Formally Included First Time in The Guide – Product and Product Goal

Scrum always was a framework to deliver complex products. However the 2020 Scrum Guide defines “product” and Product Goal formally for the first time

Scrum Guide now formally defines the terms product and product goal

Scrum always was a framework to deliver complex products. However the 2020 Scrum Guide defines “product” formally for the first time . The guide defines scrum as “a vehicle to deliver value”.

A product has a clear boundary, known stakeholders, well-defined users or customers üA product could be a service, a physical product, or something more abstract.

üIt has a clear boundary, known stakeholders, well-defined users or customers üA product could be a service, a physical product, or something more abstract.

This definition clarifies the misconception that a product is a tangible item and a service which is inherently intangible can not be termed a product and as such scrum teams cant work on a service , the guide now states transparently that

A Product has has a clear boundary, known stakeholders, well-defined users or customers.
A product could be a service, a physical product, or something more abstract.

A product goal is defined as the long-term objective for the Scrum Team. It describes a future state of the product which then serves as a target for the Scrum Team to plan against. This goal is included in the product backlog and in fact is a “commitment” that drives “what” gets added in the product backlog.

Scrum team has one product goal and the team must fulfill or abandon the goal before moving on to next product goal

Scrum Guide 2020 – What’s New?

Scrum Guide 2020 – What’s New?
Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Over the years Scrum Guide has changed considerably. A very key point to keep in mind would be that “Scrum” has not changed – Jeff and Ken have inspected and adapted the guide to Scrum so that Scrum is articulated clearly and concisely.

Here, in this series, I have articulated my understanding and perspective on how the guide has evolved in its latest avatar. Some Of the themes I want to explore in this series are::::

Purposefully Incomplete – First time, the authors have put it on the paper that scrum guide is Purposefully incomplete. In my eyes, this drive to make things less prescriptive is behind many of the changes in scrum guide.
Some Ideas Formally Included First Time in The Guide – Some ideas and Principles like Lean , product goal , formal specification of commitments are formally included first time in this guide. Some of these were already practiced by many as a beneficial. Now they are included in the guide formally. This formal inclusion helps to further the Scrum cause of focusing on value
Some Changes That Bring in More clarity – Along with concepts formally included for the first time, we can see some small but significant changes. These changes bring a wonderful clarity. Some items in this list are rewording of scrum master being a servant leader or the team being “self managing” instead of “Self organized”
What Has NOT changed – Perhaps the most important theme, I want to explore. Scrum is delightfully incomplete and its a very satisfying exercise to contemplate what has not changed and more importantly why? These are the aspects of scrum that provide the anchor to our thought process.

Myth about Sprint Review being a sign-off event or a demo forum

Teams some times think of Sprint Revierw as a “sign off” from the Product Owner – this reduces the opportunity to get feedback from stakeholders –

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-review-being-a-sign-off-event-or-a-demo-forum/

Myth about baselining the Sprint Lengths at the start of the project

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing the a contract – But like everything in scrum, the Sprint length needs to be open for Inspection and Adaptation

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.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-baselining-the-sprint-lengths-at-the-start-of-the-project/

Myth about Definition of Done being baselined before project starts

definition of done is often looked at a checklist that is set in stone-something not evolving – let us discuss how Definition of done evolves

Common Misconceptions and negative implications

Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
For example : One could start with a definition of done as
- Acceptance criteria for functionality is met
- User Documentation is completed
- Integration testing is done
- Regression testing is done
As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
- Acceptance criteria for functionality is met
- User Documentation is completed
- Integration testing is done
- Regression testing is done
- Performance testing is done

So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-definition-of-done-being-baselined-before-project-starts/

Myth about Daily Scrum being a status meeting

Daily Scrum is an opportunity to inspect and adapt -its NOT a Status event

Common Misconceptions and Negative implications

Most teams conduct Daily scrum as a status meeting. When this happens, following negative implications result

Developers start thinking that this is Scrum Master’s forum
Developers don’t take accountability
Developers lose interest and start saying “there is nothing to status report every day”

Recommendations:

Primary intention of Daily Scrum is to Inspect and Adapt. This is supposed to be a forum where the Developers finds out if things are going in the right direction. If they are not, then it is time to discuss the same and adapt as soon as possible. If required, the scope needs to be adjusted, decisions need to be taken so that the Developers comes back on track.
It is good to keep the “Sprint Goal” at the centre when the Daily Scrum discussions are on. This is not about day-to-day tasks. This event is about knowing if we will be meeting the “Sprint Goal” or the business objective.
The three questions (while they are not compulsory in Scrum) actually are mis-understood by most teams. The three questions are not about “What did you do?”, “What are you going to do?”, “What are your impediments?”. The tree questions are about Sprint Goal and not about what tasks you are doing . So the correct 3 questions are

· What did I do yesterday that helped the Developers meet the Sprint Goal?

· What will I do today to help the Developers meet the Sprint Goal?

· Do I see any impediment that prevents me or the Developers from meeting the Sprint Goal?

Daily Scrum is also an important opportunity for collaboration for the Developers. Scrum Master is actually a facilitator in this forum. Scrum Master’s job is to make sure
- The Daily Scrum happens
- Negative things which happen regularly are prevented
- To make sure that it finishes off on time within 15 minutes and teams are free to go back to work.
The only mandatory participants of Daily Scrum therefore are the Developers members and not Scrum Master and Product Owner. PO if at all joins, his presence is limited to clarifying scope.

This article is re-published on WORLD OF AGILE website – https://worldofagile.com/blog/myth-about-daily-scrum-being-a-status-meeting/

Agile tester : Skills Needed

In last post we discussed about how the role of a tester changes in agile world. To cope with the changed world, a tester needs to acquire a few new skills. This post discusses what exactly needs to be done

Whenever the two words agile and tester come in one sentence, the next word to be expected is automation. While automation does form a part of the skill repository of tester, its not the only skill they need to acquire to fit in agile world.The diagram above showcases snapshot what needs to be learnt new by a tester in order to thrive in this new world!

Scrum Framework – This category is self explanatory 🙂 A good tester needs to know the framework he or she is operating in. In most of the agile projects – the framework is scrum. The Tester needs to know the same
Common Agile Practices Agile projects use some practices not mandated in scrum. Knowing these practices helps the tester. Some practices like TDD/BDD or Integrating testing in CICD pipeline in fact keep more focus on testing. Testers need to learn these practices well
Agile mindset More than the events and artifacts, agile projects are set apart by the principles and values which the team adheres to. It is critical that the testers really need to understand how the thought process differs. An agile project will focus on getting user usable deliverable out at every sprint. This singular goal drives all activities including testing. A tester needs to now wear the hat where he helps the developer ship out defect free code – The focus now is not finding maximum defects but on ensuring defect free delivery.
Feedback loop A tester in agile project works with frequently changing requirements. This necessitates a ongoing discussion between tester and business community as well as developer. The tester should continually update the business community on the testing impact the new requirements have! He also needs to work with developer to pass on insights that he has from his testing till date. These can be typical defects , areas which the tester think will have down stream impact etc. Testers have a wealth of knowledge that can enable the developer to deliver a best in class code. A tester should be conscious of his responsibility to have this constant feedback going. On the other hand, a tester needs to actively seek inputs on how his tests are impacting project. Are they helping to avoid defects in later stages? or they are just a time waste? Having this feed back loop going in both directions will help a tester to do his job efficiently
Involvement In Events – I have seen cases where test team is absent from events like planning , daily scrum or the sprint review. Tester is very much a part of the whole team and needs to be an active participant in each event.
Automation Automation is the word one hears often whenever agile is mentioned. A tester needs to learn not only functional automation but also need to automate test triggers.

Agile Testing:: Role Of tester

The role of a tester in an Agile team includes activities that generate and provide feedback not only on test status, test progress, and product quality, but also on process quality. These activities include:

Understanding, implementing, and updating the test strategy
Measuring and reporting test coverage across all applicable coverage dimensions o Ensuring proper use of testing tools
Configuring, using, and managing test environments and test data o Reporting defects and working with the team to resolve them
Coaching other team members in relevant aspects of testing
Ensuring the appropriate testing tasks are scheduled during release and iteration planning
Actively collaborating with developers and business stakeholders to clarify requirements, especially in terms of testability, consistency, and completeness
Participating proactively in team retrospectives, suggesting and implementing improvements

Within an Agile team, each team member is responsible for product quality and plays a role in performing test-related tasks.

Agile organizations may encounter some test-related organizational risks:

Testers work so closely to developers that they lose the appropriate tester mindset
Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within the team
Testers cannot keep pace with the incoming changes in time-constrained iterations
To mitigate these risks, organizations may consider variations for preserving independence.

The Role of a Tester in a Scrum Lifecycle

Throughout this study content, general reference has been made to Agile methods and techniques, and the role of a tester within various Agile lifecycles. This subsection looks specifically at the role of a tester in a project following a Scrum lifecycle .

Teamwork

Teamwork is a fundamental principle in Agile development. Agile emphasizes the whole-team approach consisting of developers, testers, and business representatives working together. The following are organizational and behavioural best practices in Scrum teams:

Cross-functional: Each team member brings a different set of skills to the team. The team works together on test strategy, test planning, test specification, test execution, test evaluation, and test results reporting.
Self-organizing: The team may consist only of developers, but ideally there would be one or more testers.
Co-located: Testers sit together with the developers and the product owner.
· Collaborative: Testers collaborate with their team members, other teams, the stakeholders, the product owner, and the Scrum Master.
Empowered: Technical decisions regarding design and testing are made by the team as a whole (developers, testers, and Scrum Master), in collaboration with the product owner and other teams if needed.
Committed: The tester is committed to question and evaluate the product’s behavior and characteristics with respect to the expectations and needs of the customers and users.
Transparent: Development and testing progress is visible on the Agile task board.
Credible: The tester must ensure the credibility of the strategy for testing, its implementation, and execution; otherwise the stakeholders will not trust the test results. This is often done by providing information to the stakeholders about the testing process.
Open to feedback: Feedback is an important aspect of being successful in any project, especially in Agile projects. Retrospectives allow teams to learn from successes and from failures.
Resilient: Testing must be able to respond to change, like all other activities in Agile projects.

These best practices maximize the likelihood of successful testing in Scrum projects.

Initial Set Up Activities

Like all areas of project, testers need to do some preparatory work in first iteration of the project . The tester collaborates with the team on the following activities during this iteration:

Identify the scope of the project (i.e., the product backlog)
Create an initial system architecture and high-level prototypes
Plan, acquire, and install needed tools (e.g., for test management, defect management, test automation, and continuous integration)
Create an initial test strategy for all test levels, addressing (among other topics) test scope, technical risks, test types, and coverage goals
Perform an initial quality risk analysis
Define test metrics to measure the test process, the progress of testing in the project, and product quality
Specify the definition of “done”
Create the task board
Define when to continue or stop testing before delivering the system to the customer
Sprint zero sets the direction for what testing needs to achieve and how testing needs to achieve it throughout the sprints.

Integration

In Agile projects, the objective is to deliver customer value on a continuous basis (preferably in every sprint). To enable this, the integration strategy should consider both design and testing. To enable a continuous testing strategy for the delivered functionality and characteristics, it is important to identify all dependencies between underlying functions and features.

Test Planning

Since testing is fully integrated into the Agile team, test planning should start during the release planning session and be updated during each sprint. Test planning for the release and each sprint should address the issues.

Sprint planning results in a set of tasks to put on the task board, where each task should have a length of one or two days of work. In addition, any testing issues should be tracked to keep a steady flow of testing.