How to evaluate suspicious tasks?
While refinement we can have suspicious tasks, behind the task there can be a deep struggle, but we don't know for sure, so the question is should we take into account this suspicious?
Can you give an example of what you consider to be a "suspicious task" and how the team came about determining that this task is something that needed to be done?
Why not conduct an investigatory spike during Product Backlog refinement?
Isn't Product Backlog refinement "Refinement" when we evaluate tasks?
Isn't Product Backlog refinement "Refinement" when we evaluate tasks?
For instance, I a few times struggled with communicating with the third-party system, and when we are getting task one more request to a different point of the system, I have suspicious that again we will have trouble, and the task is just about retrieving number. If I didn't have such trouble with the third-party system I would evaluate 1, but because of suspicion, I evaluate with 3 points.
Can you eliminate the suspicion altogether? A spike to investigate might be a good technique.
Sometimes running a survivable experiment is the appropriate way. This could range from phoning the customer to ask what they want, how they will use what you intend to build, and learning what they do/don't need.
Sometimes it needs more extensive investigation, such as running an A-B experiment, or building prototypes.
It might be that the only suitable way to learn is to get on, build and release something. In which case, perhaps you would break the task down to the smallest use case that allows validated learning to take place.
Once the work becomes small, the amount of time that is risked becomes smaller, and that should make it easier to accept if it's not a worthwhile investment for now, and move on to something else
If you estimate, just take any doubts you may have as a factor that increases the complexity, how you will deal with this later depends on your context and joint team decision, as it boils down to:
- You (as a team) feel comfortable with forecasting particular PBI within Sprint timebox, or
- You feel uncomfortable with it, which may indicate that more Refinement is needed - which may be i.e a Spike.
Regardless of what number you produce by your estimation technique, it will never be true - it is only a concept that should lead to a better understanding of PBI in hand. In the end, it may resolve in real life that your doubts were unnecessary and everything goes so smooth that you "finish 2 days earlier". It may be also the opposite and the work needed will only grow and grow down the rabbit hole.
Your "friend" is the Daily Scrum, at least once per day you stop to Inspect and Adapt your work and joint effort towards the Sprint Goal. When a "small PBI" becomes too big during the Sprint, what will you do?
During the Refinement, in my opinion, you should often ask if in discussed PBI is something that you can do better (using your best judgment):
- Can you split it even further so that it still makes sense?
- Are there any doubts and questions that you should tackle before considering this PBI in the next Sprint? (This is actually a Refinement activity - as much as needed to consider something ready for next Sprint, as little as possible to limit the risk of waste)
- Do you feel confident enough that this PBI is doable within the Sprint timebox?