Argthtjtr

Scenario: I was asked by management if it is a good idea to add test cases to user stories before the sizing session. This will involve investigating the item, writing test cases, speaking to developers / architects to ensure areas are covered and adding more if needed.

During a normal sizing activity, the team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. From a developers perspective, they don't build a prototype, they discuss the item and then size the item.

So after doing some research, I am not comfortable for the team to create test cases before sizing because there might be discussions in the sizing session and we might uncover issue with acceptance criteria or the priority might change or technologies might change, as we know the IT industry is always evolving.

I think this should be factored in with the sizing session. The test cases can be created after the item is pulled into the sprint.

Have anyone tried this before or do you have any concerns or ideas that might help.

A short answer to start with. If you have the Product Owner available with a well-defined list of Acceptance Criteria against User Stories, your agile team can conduct an effective Story Sizing session.

Agile estimation (specially the Story Points estimation technique) is based on relative sizing. You need don't need to have 100% clarity to estimate stories based on relative complexity and effort required to complete them.

Scrum framework does not dictate whether the team writes test cases or not. The expectation, at the end of every sprint, is to complete the sprint backlog as "done".

Acceptance criteria is generally the source of test cases (whether manual or automated). AC are the conditions which will satisfy the PO on the working software that the team delivers after the sprint. Before test cases can be written, the PO should write good user story and acceptance criteria.

Test scripts will make sure that the software meets the acceptance criteria under various scenarios and situations. While writing test cases a team member may come across unknown areas that would require changes in the existing acceptance criteria. Which is absolutely fine in the agile world. There are different approaches to tackle this learning/change.

For the sizing activity, discussion between PO and team is more important then having details in form of test cases, including performance, load, negative scenarios which may be useful later on but is a waste at the moment.

Scrum is a balancing act between:

• Preparing user stories so that the team can effectively work on them in sprints


• Not doing too much up front work so that you are able to respond to change.

Every team needs to find the right balance point that suits their organisation and way of working.

If you spend time producing test cases on stories in the backlog then you may be better prepared for sprints.

However, there are a number of disadvantages to this approach:

• If priorities change or new work appears that the effort spent will be wasted or there is an opportunity cost - you could have better spent your time elsewhere


• There is the risk that if you put a lot of up-front effort into stories that there will be a reluctance to accept change


• As you mentioned, there is the risk of technical changes or discovery invalidating some of your work

I would suggest that if you do decide to add test cases in advance you treat it as an experiment. Give it a period of time (say 3-4 sprints) and then see if it has worked out to be of benefit.