2 min read

Should Stories & Bugs Follow Different Workflows?

By Joseph Lane on Mar 31, 2021 10:07:00 AM

Blogpost-display-image_Should stories and bugs follow different workflows-The short answer: Not really. Stories and bugs are both software development items by different names. As such, the vast majority of activities and controls that we model for a story are applicable to bugs. The key distinction between stories and bugs often comes down to data. Bugs should include Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior. How and when we require this data relies on what practices we're observing.

For teams using Kanban practices where there is a Backlog status and a Ready for Development status, the transition to Ready for Development can be used to capture required data based on issue type. In this simple case, we would have two transitions from Backlog, Ready for Dev and Ready for Dev - Bug. For each transition, include a transition-specific screen to capture the appropriate fields.  Example: SDLC Ready for Dev - Bug Transition Screen will include: Affects Version/sSteps to Recreate, Expected Behavior, and Actual Behavior in addition to any other fields needed in both cases. Then, leveraging your workflow conditions allow the Bug issue type to only use the Ready for Dev - Bug transition. All other issue types can default to the Ready for Development transition by explicitly checking that the current issue type is not a bug.

The considerations above work well in workflow cases where you have gated controls as a function of status change. This might apply to teams that include requirements definitions and design efforts within the story or bug life cycle (as might be the case with Waterfall). Additionally, this logical approach allows for workflow reuse which in turn decreases administrative burden and increases process consistency.

Scrum teams view Ready for Development a bit differently. Good Scrum practices dictate that product owners will refine their backlog as items are prioritized upward. Refinement provides all functional details necessary for the scrum team to be able to work the ticket including validation of bug reports and associated details. Once prioritized, the development team will review stories and bugs at the top of the backlog to make sure they understand the requirements. The work is considered Ready for Development at the moment it is accepted in to a sprint.

I hope this explanation helps you avoid unnecessary workflows!

Topics: blog best-practices bugs kanban scrum workflows software-development coding
4 min read

Do testers need to be in sprint planning?

By Marcelo Garza on Mar 3, 2021 11:30:58 AM

Blogpost-display-image_Why do testers need to be in sprint planning-In today’s business environment, high-speed implementation is a must. This applies to all products and services. Suppose you were using an application and got stuck because of a bug: after reporting the bug, you expect the team to fix it as soon as possible. If not, your next move is probably going to be switching to another service.

Software companies want teams working together providing quick and on point solutions to save time and resources, which can only be accomplished by the involvement of all of the teams working on a project. That’s why companies are opting for testing with Agile teams, since it allows for a greater collaboration across teams on a project. 

Agile allows a key collaboration between testing teams and developers which can’t always be accomplished with traditional approaches. It enables testers to share their perspective from the start of the sprint planning; this leads to less bugs during testing and creates a better possibility for sprint delivery dates to be met on time.

Let’s dig a little deeper to understand what this means.

The objective of Agile/sprints/scrum 

Agile methodologies were born as an alternative to traditional software development approaches, like waterfall methodology. 

The following images show the big difference between agile and waterfall methodologies. (Source)

wCXkvvXwQxlBYxwzr_327Yp6iURV_I96Tp1aH_7sZ_o-nN_WgAHqwLsCGZhKraLYAj96nyay0z6VH3GqeZvv7HdSwF1OCGvp

On one hand we can see that the traditional approach (Waterfall) aims to understand user needs and develop a product. After development, testers test the product and report bugs before deployment. The development team then works on them and fixes any errors using the best possible solution. This is progress through phases, one starts only when the previous one ends; this does not create an opportunity for proper feedback or collaboration between testing, developers and users teams.

On the other hand, Agile is mainly focused on performing constant, small deliveries of the product in order for the customer to be able to see how the product advances through the lifecycle. This gives the opportunity for testing to take on a bigger role and to get involved at an early stage of product development and throughout all the lifecycle of the product.

Agile has four important values:

  1. The focus should be more on individuals and interactions instead of processes and tools

  2. Working software is more important than comprehensive documentation

  3. Customer collaboration is more vital than contract negotiation

  4. The process should respond to change rather than follow a plan

Testing in sprint planning: The goal of sprint planning

During sprint planning, the team discusses which stories they will focus on in the upcoming sprint based on aspects like priorities, time frame, feasibility, etc.

The whole team involved in the development of the product should be involved, and if additional expertise on specific backlog tasks is required, then stakeholders can also be part of it.

Sometimes, during this meeting, the testing team can take a secondary role since the main focus tends to be on the development of the stories; this is understandable since it will set the start of the sprint. However, the testing team's' perspective can lead to some serious benefits for developers.

Why testing should be involved

One flaw of working in traditional testing (i.e. Waterfall methodology) is that during the test case design phase, although testers receive the requirements, most of the time they don't get access to the software they will test until it is time to begin the test execution phase.  It is well known that there is usually a big gap between what a requirement specifies and the actual software developed. 

This leads to a huge time investment on the testing side to reach out to both developers and users to define how the product works and how it should work in order to define the correct test scenarios and test cases.

Agile methodologies give testers the opportunity to be involved in the development of the product from the get-go. Testers can be involved in the design of the software by working closely with developers to assess and advise on testability aspects.

An Agile tester should understand the relevance of technical skills. A tester is always prepared to contribute to the technical discussions of the team. Their contribution may extend up to code reviews, user stories grooming, and understanding requirements. The Agile Software Tester gets to work with the developers when they are performing unit testing and share the perspective of testing from a tester's point of view instead of a developer's. The tester can work collaboratively and productively with the product owner and the customer to form acceptance criteria from the sprint planning itself. 

Before any user story is sent for development, the tester and other team members can discuss the complete user story with the team members to find out what the customer wants. Having testers collaborate with developers from the very beginning of sprint planning helps to achieve more accurate estimations and to ensure that everyone has some testing tasks as part of their responsibilities

Great testing teams know they need to become an extension of the customer and end user. Testers need to understand the customer's needs: an Agile tester should be able to describe the feature as well as the customer.

Drop us a line for expert advice on testing and all things Agile, we'd love to help your teams achieve their true potential.

Topics: blog testing tracking collaboration agile software-development

Praecipio Consulting is an Atlassian Platinum Partner

This means that we have the most experience working with Atlassian tools and have insight into new products, features, and beta testing. Through our profound knowledge of Atlassian environments and their intricacies, we can guide your organization as you navigate these important changes.

atlassian-platinum-solution-partner-enterprise

In need of professional assistance?

WE'VE GOT YOUR BACK

Contact Us