AgileIQ Blog

Product Owner Anti-Patterns, Part 4: Copy the Old One

by Monica Yap

In my earlier blog posts in this series, I shared the Absent Product Owner, the Churning Backlog, and the No Single Product Owner anti-patterns. Now I'd like to discuss Copy the Old One.

Anti-Pattern 4: Copy the Old One

This is very common: When the project is to build a new application to replace an old one, the Product Owner does not create stories or prioritize the backlog, since they are “all there in the old application”, therefore we don’t need to start from scratch and should rebuild all the features in the old application. In reality, often the business environment has changed due to changes in the market or work flow improvement, etc., so some of the features in the old application became obsolete, and new requirements have emerged due to the changing environment, so when we rebuild the new system we need to actively trim those obsolete features and add new/change features. Furthermore, if the old application was built in the traditional Waterfall process, there were probably excess features built into the old application due to the “all requirement must specified up front” scenario (see the Standish Group Study below).

When this anti-pattern happens, the team has to “act” as the PO role and learn the old application via code or specification, and many times what they learn is outdated, or the old system didn’t have the correct features according to the documentation. This will causes many frustrations between the PO and team, and trust no longer exists since the team can be perceived as “they didn’t do what they were supposed supposed to do”.

Smells:

• PO asks the team to “just read the old application’s specification or documentation”, “just read the old code”

• PO takes a screen shot of the old application and ask the team to reproduce it

• PO refuses to prioritize or explain the stories

• PO may not know how or why the system behaves as it does

Remedies:

• Help the Product Owner and stakeholders understand:

• The possibility of rebuilding unused features (use industry studies and data like the Standish Group study).

• The old code may be wrong, providing inconsistent or inaccurate behaviors that users haven’t detected, or users just had to “live” with it.

• The old specification may be outdated and not accurate.

• Collect a list of the current user roles and conduct a user story workshop with a representative from each group. Start with the user stories you created in #2, ask them to update them according to their current environment (i.e. market condition, workflow, etc.).

• For each of the features in the old application, use the User Story template (below) to identify the current user role, feature, and value. Note that a user role should not be ‘System’ or ‘other applications’: if you cannot identify the user, then there is a good chance this feature may not been used or the need has changed over time.

• Build up the Product Backlog with the help of the stakeholders to prioritize for the first release.

• There is ROI in multiple releases throughout the project which can mitigate many risks (<fill in for your specific context>), so prioritizing the stories into releases can help gain business value earlier and avoid those risks. Create a high-level roadmap for multiple releases and look for opportunities for early releases -- perhaps a small module can be released and coexist with the current application.

• Identify acceptance criteria for the user stories in the upcoming Sprint, since the team cannot be ‘done’ without properly identifying the story criteria.