Split work item into prototype and main work item?

Question

During grooming, we usually have work items which get approved based upon the team understanding that what needs to be done? The product owner does not discuss the details of how it will be done and stops the discussion if team tries so. This applies to all work items (new UI, new API or changes to existing UI/API). Product Owner's reasoning is that getting into the details (both technical & functional) of how it will be done is something that needs to happen during sprint and discussing it during grooming is not correct. The effort estimation also happens based upon this discussion.

But during sprint planning, approved items are taken for the sprint and expectation is that if work item is approved, team should know all the details of the solution and should be able to complete the item in sprint. What happens is team spends first 2-3 days in doing the research and getting the PO's approval for the solution (UI design, key business logic clarification). Unless the analysis results in great difference in effort estimate, team is asked to complete the feature. This happens in each sprint.

I dont have a problem with putting extra effort in completing the work item. My question is regarding the process.

1. Should the team say no in approving the item unless team understands how the solution will look like?
2. Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.
3. Any other suggestion as to how it can be handled in better way?

Answer 1

The level of detail at the planning meeting depends a lot on the personality and expertise of the PO.

Take user interface as an example: Some product owners have strong UX skills or use UX experts outside the team. These PO's better come with a rough UX spec to the planning meeting. In other cases this skill is more present inside the team. Those teams handle the UX design as part of the implementation. The problem arises if the PO has strong opinions about the UI, but fails to communicate in advance what he wants. That is unfair towards the team.

In short, if it affects the acceptance of a work item, then the PO should not avoid the question at planning meeting.

On the other hand, you can't expect him to have all the answers prepared, the team must also think actively and give him some options to choose from.

One good way to approach this at the planning meeting, is to formulate questions to the PO as "would you accept the story if ...".

Back to your questions:

Should the team say no in approving the item unless team understands how the solution will look like?

Yes, if the PO is unable to give clarity on what he will accept and what not.

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

If for a certain work item, you all feel an iterative approach would be best ("let's see how this works, and then decide if it needs a change"). Then it is better to split it into two items. But don't think of step 1 as a prototype, make it "potentially shippable" based on current understanding of the team and PO. The PO can always define work items to improve it later.

Any other suggestion as to how it can be handled in better way?

Some teams or PO's will prepare rough UX specs (wireframe) before the planning meeting: Aim for early failure. Just enough to agree on. So that when the team commits to a work item, the scope has been clarified in advance.

Answer 2

Another way of doing it, is by splitting the session into two parts.

In the first one the Product Owner goes into the level of detail that the team needs in order to understand the requirements. No effort estimation will be done during this part. Then the PO leaves the room and the team starts with the estimation process the includes the "how it will be done".

The PO should be be available to answer questions that will come up. This is an important part of the sprint planning where you can include planning poker or any other estimation techniques. It is important that the planning will not take forever and you should have an end time where you close the session.

Anything that the team considers important should be discussed during the planning session. It is good practice. If the team leaves the room and have lots of questions it's impossible be productive. In case there are too many unknown factors then you could start a spike to research a concept and/or create a simple prototype. But it should be the exception and not the rule.

Answer 3

Should the team say no in approving the item unless team understands how the solution will look like?

No, of course not. Not knowing the implementation details leaves the team leeway in finding the simplest solution later on. This doesn't mean that discussion should be prevented, but it should certainly be limited.

Suppose for example that in the planning meeting it is decided to play a story in a certain way. Should the team be forced to use that design during the sprint? That is contrary to the agile manifesto.

Should the work item be splitted into research/analysis in which solution prototype will be proposed to the PO? Once the PO will approve the prototype, the main work item will be marked approved.

No, this won't help the team, because prototypes have no value for your users, and therefore should have the lowest priority according to Scrum. You should only do prototypes if needed once you commit to the story, not before.

Any other suggestion as to how it can be handled in better way?

I have a few:

1. Why is your product owner acting a Scrum Master? The roles should really be separate, and doing otherwise is generally a Bad Idea™

2. Why are you estimating your stories two times? This should not really happen. You estimate them once, imprecisely, to get an idea of what fits in a sprint. No one should care beyond that point -- the measure becomes what you actually accomplish. Of course, there can be task estimates, but they are purposefully in a separate set of units because they should never be used to estimate what fits in a sprint, but only how much work is left.

3. You seem to have a problem in collaborating with the PO during the sprint. For example you say the "team struggles during first 2-3 days in doing the research and getting the PO's approval for the solution". This makes no sense to me. The PO should be concerned with the end result for the user and not committed to a particular solution. They get to specify some end-to-end acceptance tests before hand, but everything that passes them is fair game -- anything else should be a new story.

4. Your suggestion of having a prototype->story pipeline goes against collaboration and towards a separation of roles. What you really need, instead is to have PO and team collaborate during the whole sprint and talk to each other. The stories should not be designed until they are done. What you call a "prototype" should really be the story.

Answer 4

In my opinion your problem its here:

"Unless the analysis results in great difference in effort estimate, team is asked to complete the feature."

Another company that want to "be agile" for don't spend time in estimation and a more in depth definition of US (and that its totally ok), but there are not "agile" enough to understand the difference between an estimation and a compromise.

The SM its the one that need to explain this to the management, and if the situation where the team need to work overtime for complete features its the norm sprint after sprint the SM must put immediately and end to this nonsense and recover a sustainable pace for the team.

Having sustainable pace its one the core values of agile, finishing all included US in a sprint of course its not. In the long run the first its much more important than the second, its key to understand this.