Monday, April 24, 2017

Often times we come across poorly written backlogs and defects. This not only leads to confusion but also creates rework in the sense that spending time to understand what is happening to the system and what are the expectations from developer or tester.
As someone said, clarity is divine. Without clarity there is chaos and confusion; ultimately this leads to delays is the software delivery. Maintaining clarity helps involved stakeholders in following manner –

To identify work involved

To come up with list of tasks, before actually working on the backlog or defect.

To come with any proposals that can be shared with stakeholders for approvals (if required)

To know risky areas upfront as far as possible

To know dependencies/bottlenecks before working on the tasks

Why should we provide details in the backlogs (or user stories)?

Clarity on the use case to the developer

To determine priority by the product owner and/or marketing

After some time gap there is possibility of even submitter not remembering about how to reproduce the defect

When we provide details, we come to know whether backlog is too big, if it is, then backlog needs to be broken to fit into one single sprint (just in case anything is missed in backlog grooming)

What should be provided in the backlogs (or user stories)?

Crystal clear acceptance criteria is must. In absence of it, developer and tester cannot know what is the measuring criteria to mark the backlog as done

To write test cases clarity on acceptance criteria comes handy

Some of the generic tasks like code review, document update, test case writing must be added by default. In version one this is possible by creating Template Backlogs.

As far as possible list of tasks to be done should be added to avoid rework on tasks identification.

A wireframe/screenshot of UI (if applicable)

Establish dependencies between backlogs

Map to parent Epic as far as possible, this associates a chain of requirements

Why should we provide details in the defects?

To let severity determination by the product owner and/or marketing to prioritize the defect. Detailed information on the defect helps in the decision process.

To let developer reproduce defect on his own

To make developer, tester and other stakeholders on the same page

What should be provided in the defects (or user stories)?

Exact use case with steps

Observations after performing the steps

What is the expected behavior from your perspective

Initial severity, based on the pre-existing shared guidelines

Initial priority, from your perspective (this can be discussed and then updated too)

Build and release number of the software, service pack number and other useful info on which issue is seen

Common for both backlogs and defects

When discussion happens on the backlog/defect it should be captured and attached to it in the system. In future this helps to understand the requirements etc. for new comers and can be used as requirement documentation.

Map to parent Epic as far as possible, this associates a chain of requirements that can be easily viewed

Provide/attach any external links where discussion happened or that may help to understand the requirement

Friday, February 3, 2017

On one particular PC after software installation, whenever user
tried to launch the application, software installation configuration dialog was
popping up continuously. And this was observed on very few PC’s.