Simulador Test Professional Scrum with UX

Learning is a first-class citizen in product development. Learning activities such as interviews can be represented within a PBI associated to a user problem (e.g. a User Story), have specific PB or performed as part of the refinement.

• It is a good practice that interviews are done by other Scrum Team members in addition to the Product Owner.
• They do not need to be done in staggered Sprints previously to their development.
• Sprint Review is an event to share the learnings obtained during the Sprint, not to do interviews.

From the Scrum Guide 2020:

• «It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
• They are also self-managing, meaning they internally decide who does what, when, and how.
• The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.»

That may not include organizational constraints, such as budget, team members, technical strategies, policies or others

From the Scrum Guide 2020:

«The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.»

From the SG 2020:

«The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.»

The course defines UX Design as:

An umbrella term that encompasses the design of every aspect of a person’s interaction with an organization, its products, and its services. That may include:

• Strategy: User Needs / Product Goals.
• Scope: Functional Specifications / Content Requirements
• Structure: Interaction Design / Information Architecture.
• Skeleton: Interface Design / Information Design / Navigation Design
• Surface: Sensory Design

A marketing persona is based on data from buying habits, while personas and proto-personas are based on usage habits. A persona requires a formal reseach effort, while the proto-personas can be defined using quick activities within the Scrum Team and with close stakeholders.

A proto-persona is a cost-effective way to start understanding the users, but investing on research may be needed to validate the internal assumptions as more development effort is commited to the product.

A business problem statement is a definition of a problem or opportunity the business is facing, including the goals missed, how did we perceived it and the business impact observation.

It is a powerful tool to focus on business outcomes and impact, to align the Scrum Team and external stakeholders and to avoid defining solutions too early.

The most frequent activity where UX & Research is done is Product Backlog refinement, specially the most strategic one like interviews or hypotheses definition. Other UX work can be done during the PBI delivery, such as User Interface definition.

All the Scrum Team is accountable for understanding the users, their problems, the desired outcomes while proposing, testing and validating solutions. The Product Owner and the UX specialist may lead the team, but everybody else should contribute.

From the SG 2020:

• «Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how
• The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.»

A Scrum Team is most effective when it is cross-functional and autonomous to do the work. Depending on external people usually produces delays and sub-optimal decisions. Although a part-time UX professional may be effective sometimes for teams, it can produce shortages of availability from the UX professional. Teaching UX to Scrum Team members is an effective way to help them to understand UX and deliver some basic UX tasks, but they won’t probably be able to deliver the most complex ones.

Multiple teams working on the same product can increase the productivity if certain conditions are met, such as:

• Dependencies among teams are small.
• The number of people and teams keep the communication and decision-making efficient.
• There are coordination and technical mechanisms in place to reduce code conflicts.

However, a scaled Scrum initiative should only have one Product Backlog and one Product Owner.

Implementing Dual-Track Agile as two different teams and backlogs for Discovery and Delivery work may help to track more efficiently those kinds of work, but is prone to:

• Undermine transparency and collaboration between the UX and Developer professionals.
• Increase rework due to misunderstandings and decisions made without the whole team.
• Reduce the engagement from stakeholders.

From the SG 2020:

«The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items;
• Ensuring that the Product Backlog is transparent, visible and understood.»

The increment contains the Product in a «usable state». That means it should contain the software and other artifacts adhering to the desired level of quality.

Some UX artifacts won’t be part of the Product, like interview minutes or mock-ups, and therefore won’t be part of the Increment. Those are products made just to learn.

However others, such as A/B tests will be deployed to production to gather data. Other code might be considered «final» but analytics may require them to be changed.

From the SG 2020:

• «When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.
• The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts.»

Values can be taught by the Scrum Master, but all members should help others to embody them.