First do you think tester should be involved in refinement sessions
During refinement sessions what are your thoughts when estimating stories? Do you take under consideration only the testing part or the development part also?
1 Like
Quick answer on this is a yes.
- Early insight into future work
- Reviewing the design/requirement ironing out ambiguities and blind spots
- Discussing and thought about testability of the change
Part 2.
Estimates should be overall, dev and test. Timelines for when something should be completed should factor in both, as well as the overall effort.
3 Likes
Yes they should take part.
Testers should use whatever knowledge they have to estimate how long it will take to complete the work. This might mean only estimating your testing work, it might not. Just depends on your knowledge and experience. Whatever your reason, be prepared to explain it when someone asks your reasoning.
1 Like
As @ckenst & @monsieurfrench has answered before: Yes.
In my experience, this can be even critical, as testing can often be tricky and time-consuming.
In more than one project, I saw ‘simple’ features that required quite a bit of testing that wasn’t obvious. In at least one case, I noticed that part of a feature (of an ordering system) that wasn’t used ever. By suggesting not to implement it, I first started an intense discussion – and in the end, saved the whole team a full week of work.
Being involved early also allows testers to direct the solution to be (more) testable.
Concerning estimates, we stopped estimating. Instead, we’re looking back at which tickets/features were done quickly and which weren’t. This gives a good hint at what we can improve in preparing stories.
2 Likes
Interesting point here. There’s also been few occasions where I have questioned why we’re doing something and it’s ended up with the change either being canned or changing design.
It feels like this should be part of the BA work of other roles but testers shouldn’t be afraid to query why a change is being made - what the benefits are if it’s not clear to them
2 Likes
Yes it makes sense, I would encourage testers to not feel unimportant in these meetings and always ask the questions even if they feel theybare dum question. I really like it when u ask a question which wasn’t thought in design and everyone gets quite and thinking. 
1 Like
I’m not that deep in our technology stack (maybe also for good?) like our developers.
At one story (or was it an epic? We were talking about the topic more in general at an refinement) I gave the very basic idea for how to do it. The other ideas (1-2) were way more complicated and the team was relieved to have a less complex approach.
If testers are in a Scrum team, they should be in every meeting of the team. They are part of the team.
Need to understand the customer needs too and can contribute by their experience.
AND testers can test, look for problems in, design documents, requirements, process definitions etc.
3 Likes
At first I try to understand the story itself. What problem we are trying to solve and what is the intended solution direction by the PO.
This is for me independent from the role. Testers need to do this as well as developers, designers, whoeverIsOnTheTeam.
Here I also try to find problems in the requirements themselves (e.g. ambiguity) as well as I add my experiences with the product.
e.g. what (not) worked well in the existing product, how can we align the new feature to the existing ones.
We do estimations with story point and it is a kind of mix for me. Finally we have to agree on something as team.
I look primary for testing, but also take into consideration what the developers say. And developers should do that the other way. Or at least they should look for the overall complexity of the story and not just what their part is.
I often explain shortly my thoughts about testing and I speak up when I see testing being way more risky, demanding, costly than development.
Imo very important at story points: No matter how you do them, do them consistently.
Asked for a concrete time I always add that I see them for “going through the software without many problems”.
Bugs and their analysis as well as problems during testing can blow up any estimated effort.
As testing is for me about informing others about the state of the product, finally the project manager decides when I’m done with testing (In a trustful relation, and me I having a good impression about their standards, I decide on this sometimes by my own*). Technically I could test most features forever.
* This applies typically for more simple topics. At anything complex and demanding I give at least brief reports in certain frequency and ask how we should continue.
Typically multiple topics want to be tested and it is a trade-off (finally for the project manager) where to spent how much time. Risks and priorities.
1 Like