Defining Your Definition of Done

The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?

It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Check out my article published at https://blog.gurock.com/definition-of-done/ – Here I talk about some good ways to define your Definition-Of-Done –

Brainstorm with your team

The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.

For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.

By doing this exercise you are baselining your expectations from each task, independent of its owners.

Consider quality goals

If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.

For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.

Read More »

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 »

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

Defining Exit Criteria for different phases of your Agile project

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. 

In my article published at Gurock https://blog.gurock.com/agile-exit-criteria/ , I have discussed some ways to structure your exit criteria at the sprint, user story, and task levels in an agile project.

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.

Check out the complete article here – >