Exit criteria are a list of items to check off that define the end of any activity. Exit criteria can be defined for any activity you want to undertake: You can have exit criteria for cooking veggies to the desired doneness, or for a city tour to be sure you see all the sights, or for a meeting to assign action items for everyone! Exit criteria are helpful to tell you (and others involved) when to stop the activity. Specifically, for an agile project, having clear and concise exit criteria makes it easier to understand the scope and avoid going overboard while keeping a tab on your quality.
The first rule for exit criteria is to have them defined up front, before beginning the activity.
For an agile project, let’s say we want to have exit criteria in place for the end of the sprint. We will need to work on defining them at the beginning of the sprint, or at the release-planning stage. Once the activity begins, the goal is to achieve all exit criteria by the end. We cannot have people defining or changing the planned exit criteria during execution of the activity, since that will not be upholding the quality standards set in the beginning.
The second rule is to have standard exit criteria for all similar activities. So, exit criteria defined for the sprint level apply to all sprints in that release, and exit criteria defined for the user story level apply to all user stories in all sprints. This upholds the same standard of quality and expectation of work required for each of these work units.
In the article, I have discussed sample Exit Criteria for Sprint, User Story or Task level and also shown how to create your own exit criteria based on your project’s and team’s context.
The important things to focus on are having the exit criteria defined up front and ensuring follow-through by sticking to the criteria throughout your release cycle. Being consistent with checking off everything on your exit criteria list ensures a smooth flow of high-quality work.
Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.
There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.
In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!
Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.
In this post I have described three metrics that can impede your agile team instead of motivating you.
Communication is the foundation of success for an agile team. Agile teams need to set up effective communication channels and have a culture of constant communication for complete transparency.
However, there are often several challenges that act as barriers to productive communication and may lead to people problems as well as delayed or failed projects. In my article for TestRail https://blog.gurock.com/agile-barrier-communication/ , I have discussed some of the most common barriers to effective communication for agile teams, as well as how you can overcome them.
Agile teams require constant communication, so it immensely benefits the team to recognize their barriers to effective communication and take some measures to overcome these barriers. Every step taken in this regard leads the team farther down their path to true agility.
Agile transformations can be a challenging undertaking, and many organizations struggle with what is probably the hardest part of the transition: adopting an agile mindset. It is imperative that teams embrace the agile culture before they can fully embrace agile.
As I always like to say, agile is more a mindset than a process. It guides you to a better way of working and collaborating in order to deliver the most value to your users. But how you choose to implement those guidelines is up to you, and most teams coming from a traditional style of software development find this aspect the most challenging.
Teams are left to find ways to work together rather than having a process forcing them to do certain actions, follow certain processes, or organize specific meetings. There are no templates or techniques to adhere to and no rules to follow strictly.
This may come as a surprise and leave teams guessing since they are used to being told what to do and how. Agile drives them to think on their feet as they plan and replan their way through the development process. Read More–>
Being Comfortable with Visibility & Exposure
Agile gives everyone a voice and values every person’s opinion. Many teams have been used to only the manager speaking for them or having one representative in most meetings. As a result, some team members may feel flustered now that they’ll occasionally be in the spotlight. People who are not used to voicing their opinion are expected to speak in all forums. Hiding behind the team is no longer an option in agile.
This also means team members are valued as individuals and everyone’s contribution is recognized. Agile treats all team members as equals, whatever their role or designation. They are expected to estimate their own tasks, pick things to work on, collaborate with other team members, and provide value by the end of each iteration. Continue Reading–>
A walkthrough is a great review technique that can be used for sharing knowledge, gathering feedback and building a consensus. Typically, walkthroughs take place when the author of a work item explains it in a brief review meeting — effectively walking the team through the work — and gathers people’s feedback and ideas about it. These meetings may be as formal or as informal as needed and may also be used as a knowledge-sharing session with many relevant stakeholders at once.
In my article published at https://blog.gurock.com/tester-agile-walkthrough/ , I have discussed three ways agile testers can make use of this type of review for their sprint- and release-level test plans and test cases to get the entire team involved in the quest for quality.
I have also discussed how I have used walkthroughs in my agile team as a mechanism to review our sprint test scenarios with the entire Scrum team. The main areas of application are-
Walkthroughs are a quick and easy review technique to adopt, and they can be especially useful for testers on an agile team to get reviews on their test plans, test cases, and scripts. Give this technique a try, even if in an informal sense, and see how beneficial it can be!
On top of that I get to present not one but 2 talks!! My topics are
“The What, When & How of Test Automation” 45 mins
In this I will talk about preparing robust automation strategies. Agile means pace and agile means change. With frequent time boxed releases and flexible requirements, test automation faces numerous challenges. Haven’t we all asked what to automate and how to go about the daily tasks with the automation cloud looming over our heads. Here we’ll discuss answers to some of these questions and try to outline a number of approaches that agile teams can take in their selection of what to automate, how to go about their automation and whom to involve, and when to schedule these tasks so that the releases are debt free and of best quality.
“Gamify your Agile workplace” 15 mins
In this I’ll present live some innovation games and have audience volunteers engage and play games based on known scenarios. Let’s Play and learn some useful Innovation Games that can help you gamify your agile team and workplace, making the team meetings shorter and communication more fun!
Both these topics are close to my heart and I am looking forward to sharing my thoughts with a wider audience.
I am also excited to meet all the awesome speakers at the event , as well as get to know the fantastic team of organizers behind this event!
Agile is a big umbrella that covers a number of different approaches, and there is always scope for more. There are so many flavors because agile is a mindset that allows flexibility in its processes. Two of the more popular approaches are Scrum and Kanban.
Scrum and Kanban apply agile principles in their own way to empower effective delivery cycles. “Scrumban” is a term coined for a hybrid approach making use of both Scrum and Kanban principles.
In my article published at Testrail , I have explore the differences among the three methodologies – Scrum , Kanban and Scrumban. Check it out and see which of these methodologies may be right for you. https://blog.gurock.com/scrum-kanban-scrumban/
Here is a brief about the 3 methodologies –
Scrum is the most popular agile framework. It is iterative and incremental in nature and focuses on tight delivery timelines. The release time frame is split into small iterations called sprints. Work items are planned for each sprint in the form of user stories and tasks, which are prioritized based on value. Teams are small, cross-functional and self-organizing, with a product owner, a ScrumMaster and the development team.
Scrum provides channels for communication through ceremonies such as the sprint planning meeting, the daily standup meeting, the sprint demo, and the sprint retrospective, all of which contribute to the overall pace and a flexible approach to software development.
Kanban is focused on continuous delivery based on lean principles. It’s based on the flow of work and just-in-time delivery and promotes process improvement. Kanban aims to eliminate waste, increase productivity and efficiency, and have flexibility in production. The main goals are to limit work in progress (WIP), avoid multitasking and recognize bottlenecks.