Read Along – ‘The Effortless Experience’

I started the ‘Read Along’ section on my blog last year with my series on the book ‘Agile Testing’ – a much coveted book for all testers. It was a fun way to learn, get back to my reading and also share it with my readers!

2021 started with me finding myself in a new job, an exciting new role in a brand new domain! So, I am taking the Read Along series forward this year by beginning a new book that not only is relevant to my current role and is a recommended read for the ‘Customers for Life (C4L)’ team that I am a part of, but is also super relevant to every software team working on developing software that not only satisfies but wows their customers!

The book is “The Effortless Experience” by – Mathhew Dixon, Nick Toman and Rick Delsi

I will be reading the book and will post about learnings, things to remember & quotable quotes from each chapter as I progress. This is to hold myself accountable, as well as to help people looking for good reads or learnings. Hope this helps you. Have you read this book? Do share your thoughts & learnings too!

Here is a link to get your own copy if you would like to read along-

Here are the Chapter-wise posts on the book

Hope this series provides a useful overview and a fun learning experience for the readers!

Cheers

Nishi

4 Exit Criteria your User Stories must have

Planning and developing new features at the fast pace of agile is a hard game. Knowing when you are really done and ready to deliver is even harder.

Having predetermined exit criteria helps you be able to make the decision that a feature is truly ready to ship. In my article published at TestRail Blog, I compiled a list of exit criteria you must add to your user story to make it easy to bring conformity and quality to all your features.

All Tasks Are Completed

This first one sounds obvious, but it may not be. I still see many teams struggling with getting their testing done within the sprint. Developers work on a user story and deem it done, while testers are left to play catch-up in the next sprint.

Put that practice to an end once and for all by making sure that no user story can be proclaimed done without having all tasks under it completed, including development tasks, testing tasks, design and review tasks, and any other tasks that were added to the user story at the beginning.

Ensuring all tasks are completed in a sprint also mandates that you begin thinking in depth about each user story and the tasks necessary for each activity to be completed, so that you do not miss out on anything at the end.

Tests Are Automated Whenever Possible

As our agile teams move toward continuous delivery and adopting DevOps, our testing also needs to be automated and made a part of our pipelines. Ensuring that test automation gets done within the sprint and is always up to pace with new features is essential.

By having test automation tasks be a part of a user story delivery, you can keep an eye out for opportunities to automate tests you are creating, allocate time to do that within the sprint, and have visibility of your automation percentages.

I have used the following exit criteria:

  • At a minimum, regression tests for the user story must be added to the automation suite
  • At least 50% of tests created for the user story must be automated
  • Automated regression must be run at least once within the sprint

Depending on what your automation goals are, decide on a meaningful standard to apply to all your user stories.

Read More »

Things to Do Before the Sprint Planning Meeting

Scrum teams get together to decide on the work items for their next sprint in the sprint planning meeting. But is that the beginning of the conversation for the upcoming sprint, or are there some things that should be done before that?

In my latest article for the TestRail blog, find out what you should be doing before your sprint planning meeting even starts so that you can help make the next sprint successful.

Prioritize the backlog

Prioritize!

The first and most important consideration is to have a live product backlog that is up to date and prioritized with changing business needs. The product owner must have a constant eye on adding, removing, editing and updating items in the product backlog. When the time approaches to get into planning the next sprint, the product manager must bring to the table a list of the highest-value items that the team can pick from.

Research features

The product owner must spend time researching each of the features and trying to lay out in simple terms the actual need they each describe. They may use bulleted points or simple sentences to explain the feature in some detail. We see this happening mostly during or after the sprint planning meeting, but if any requirements are known before the meeting, the product owner can get a head start.

Read More »

Four Things That Can Sabotage a Sprint

Success and failure are a part of any journey. For agile teams, continuous delivery is the expectation, and that may be a hard thing to achieve. As sprints go on and tasks pile up, we may deter from the path.

Whether your team is beginning their agile journey or are already agile pros, you are bound to encounter a failed sprint at some point.

When do you deem a sprint as failed? Why does a sprint fail? What are the possible reasons, and how can you learn from the mistakes to avoid them in the future? In my article published at TestRail blog – I examine four possible reasons for a failed sprint.

Read the complete article at https://blog.gurock.com/four-things-sabotage-sprint/

Bad Estimation

Estimates cannot be completely accurate every time. But when the agile team fails to see the correct depth or complexity of a task or a user story, the estimates may go haywire, leading to a big diversion from planned timelines within the sprint.

Incoherent Definition of Done

To ensure true completeness, we must list coherent and agreed-upon definitions of done for each type of task we undertake within a sprint, be it development, testing, design, review tasks or test automation. This makes it easier to keep track of the quality of work and get every person’s understanding of the expected work on the same page.

Incomplete Stories

More often than not, user stories being developed in the sprint get stuck at some tricky juncture toward the end. Situations may arise where you reached the last day of the sprint but there are still things holding up the team:

  • Development of the story was completed but testing is still underway
  • Developers and testers paired to conduct tests but some critical issues remain in the feature that need fixing
  • Development and testing are completed but the automation script is yet to be created for regression of the feature (and automation was part of the exit criteria for the user story)
  • Code review is pending, although it is already checked in and working fine
  • Tests for the user story were not added to the test management system even though the tester has performed exploratory tests

Due to any of these reasons or a similar situation, the user story will be incomplete at the end of the sprint. At this point, that feature cannot be deemed fit for release and cannot be counted as delivered.

Technical Debt

In a fast-paced agile environment, we cannot shirk off any part of our work or leave it for later. This becomes technical debt that is hard to pay off. The longer we do not pick up the task, the harder it gets to find the time and spend the effort on it while working on ongoing tasks at the same pace… Continue Reading

Using Mind Maps for Agile Test Planning

Mind maps are a creative way of gathering ideas around a central theme and categorizing them in concrete branches. Mind maps can be useful for both personal and professional life as an organization and visualization technique. They’re descriptive, easy and even fun.

In my latest post for Gurock blog, I showcase the usage of mind maps as a technique for test planning and test design. This tool’s capabilities make your documentation leaner and ideas more visual, which benefits the whole agile team.
https://blog.gurock.com/agile-mind-map/

Be it test planning in an agile team which needs entire team’s insights and collaboration, or categorization of product features, test areas and backlog, Mindmaps can be used for all aspects and phases of the project.

Testers can generate their test ideas and have them categorized in a mind map around the central theme of the feature. The visual nature of a mind map helps them find more scenarios, see which parts are more heavily tested, and focus on main areas or branches. Once done, they can have other stakeholders take a look at it and get their opinions. This fosters brainstorming together and gathers the maximum number of ideas from the entire team.

Find useful tips to create your own mindmaps, as well as some samples for your reference in agile test designing as well as test planning. Read the complete article here ->
https://blog.gurock.com/agile-mind-map/

Share your thoughts!