Finding a Sprint Goal to a diverse team

The developers may work on a related set of features that could be bundled into a predefined Sprint Goal, but the UX/UI is working on features that will go into development in 2-3 Sprints. And the Automation engineer is working on features that have been developed half a year ago.

@Luda Fux, Though this isn't an answer, could you please clarify why they are working separately? for example are they working on different projects, products etc?

If you could do one thing that could bring them together, what would you change?

the UX/UI is working on features that will go into development in 2-3 Sprints. And the Automation engineer is working on features that have been developed half a year ago

What purpose does a Sprint serve, in this case? It doesn't sound as though people are collaborating on achieving a "Done" and releasable increment each Sprint, and have little use for the empirical process control Scrum provides.

Do you have one team?

Although a lot of what I read about incorporating UX design into a Scrum Team suggests that UX designers and engineers are members of the Development Team, this doesn't align with my experiences. Although they may support the development team as questions or issues come up, they are more closely related to the Product Owner. The work done by UX designers tends to align more closely with the creation and expression of Product Backlog Items and ensuring that the order of the Product Backlog Items is appropriate, along with helping the Development Team to understand and make informed decisions around the user experience.

There are similar problems with Automation specialists. Since it takes time to turn a set of steps into automated tests, work completed at the very end of the Sprint can't be finished with automation. However, it's easier to align manual QA and automation QA with the rest of the Development Team in two respects. First, they can share their specialized knowledge with the rest of the Development Team, improving everyone's ability to design, execute, and automate tests. Second, they can do some aspects of their work when getting work done.

I would recommend looking at your organizational structure and making sure that it has the right people. Are they all on the team? Or are some people playing more of a supporting role from time to time and need the right communication paths. It may make sense to move some people and their work onto other teams to enable you to focus on particular goals.

My impression is that you aren't doing anything related to Scrum.  You are planning multiple projects together in 2 week increments.  If you were using Scrum, then the entire team would be working on the same bodies of work that would deliver a potentially releasable increment of value at the end of the Sprint. 

My suggestion is that you focus on defining your Definition of Done(DoD) first. The DoD can put focus on a lot of bad practices. After you can all agree upon what it means to be done with work, then start working with the team to align their work on that.  For example, if the DoD includes the need to have automated tests completed, then the team needs to find ways for the Automation Engineer to be building the tests in the same Sprint as when the feature is developed. 

As @Thomas Owens stated, in most places I have worked the UX Designers are a part of the Product Management organization and provide work for the development of the ideas that will be introduced into the Product Backlog. 

As for QA, I have a long background as a QA Engineer.  The most effective method I have found for "QA in Scrum" is to have the entire team own the quality of what is being built.  The person with QA in their title can help in many ways.  Instead of waiting until the end to test and find the bugs, the individual will work from the beginning helping to prevent defects.  Refinement is a great place for a QA Engineer to start asking questions related to how they would test.  It often points out flaws in the designs the Developers have in their heads.  QA participating in code reviews from a perspective of auditing any unit, integration, system tests that are being created by the Developers.  This often shines light on ineffective tests or, unfortunately, missing tests.  Those are the most effective, cheapest tests that can be created.  And if they are effective, it can minimize the amount of testing needed to be done through the UI as end-to-end tests.  

I applaud your new found focus on the Sprint Goal but I believe you have a lot of work to do before you could even begin to start crafting any kind of useful Sprint Goal.  

Hey @Steve Matthew

@Luda Fux, Though this isn't an answer, could you please clarify why they are working separately? for example are they working on different projects, products etc?

We are working separately at the moment as the UX/UI creates the screen, then the devs developed them. This usually happens in 2 consequential Sprints. 

The automation engineer just joined the team. The automation was neglected so far, so it will take him some time to catch up. At the moment he is several months behind the dev team.

If you could do one thing that could bring them together, what would you change?

I though about taking the UX and automation outside of the team to serve several scrum teams, but that wouldn't be much of a scrum. Would it?

@Ian Mitchell

What purpose does a Sprint serve, in this case? It doesn't sound as though people are collaborating on achieving a "Done" and releasable increment each Sprint, and have little use for the empirical process control Scrum provides.

As I wrote, only now I have become fully aware of the Scrum framework and aware of all the missing parts, such as the Sprint goal. Until now the purpose was for people to collaborate on achieving a "Done" and releasable tickets picket up from the Product Backlog. This instead of having a cohesive Sprint Backlog with overarching Sprint Goal. 

@Thomas Owens

Although a lot of what I read about incorporating UX design into a Scrum Team suggests that UX designers and engineers are members of the Development Team, this doesn't align with my experiences. Although they may support the development team as questions or issues come up, they are more closely related to the Product Owner. The work done by UX designers tends to align more closely with the creation and expression of Product Backlog Items and ensuring that the order of the Product Backlog Items is appropriate, along with helping the Development Team to understand and make informed decisions around the user experience.

There are similar problems with Automation specialists. Since it takes time to turn a set of steps into automated tests, work completed at the very end of the Sprint can't be finished with automation. However, it's easier to align manual QA and automation QA with the rest of the Development Team in two respects. First, they can share their specialized knowledge with the rest of the Development Team, improving everyone's ability to design, execute, and automate tests. Second, they can do some aspects of their work when getting work done.

I would recommend looking at your organizational structure and making sure that it has the right people. Are they all on the team? Or are some people playing more of a supporting role from time to time and need the right communication paths. It may make sense to move some people and their work onto other teams to enable you to focus on particular goals.

This is exactly what I am thinking. I just worry that it. would be going against Scrum. Another thing that concerns me is how to go about it to the management. This is a high profile question, and I am just a Scrum Muster of a team. 

I though about taking the UX and automation outside of the team to serve several scrum teams, but that wouldn't be much of a scrum. Would it?

When you say several teams, are these teams all working from the same Product Backlog for the same Product?

When you say several teams, are these teams all working from the same Product Backlog for the same Product?

Same product, but different Product Backlogs. This should (and I believe could) be changed as well.

Same product, but different Product Backlogs. This should (and I believe could) be changed as well.

Interesting!

Now that we know that, if we asked all these people (developers, automation, UX, QA etc) what's the best way for them to work together as a team, or teams, to create an integrated Increment within a Sprint (assuming there aren't other dependencies) what are some ideas they may come up with?

Most obvious to me is that you appear to have highlighted a bottleneck in the automation part of your workflow. That's not going to resolve itself. It may be necessary to hire more people to cope with the workload; but I've personally experienced greater success with our QA engineers stepping back from writing automated tests, and moving into a servant leadership / coaching role, with the other engineers taking on the responsibility of writing automated tests for their own code.

Short term, this can dramatically slow down development. Longer term, it can have a positive impact on reliability, as engineers have more context on how to test and code to ensure sufficient quality.

But aside from anything else, if automated testing is required, then having a 6 months lag in that testing is a dangerous liability, and having the team slow down the release of new, untested functionality for now might be necessary to avert a serious business risk.

-----

How much of the UX/UI work can be deferred to the same sprint as the other development work?

I imagine your UX designers/experts will be heavily involved in Product Backlog refinement, particularly as there is a longer lead time in some aspects of what they do; but the balance can almost certainly be reduced from what you describe. For instance doing just enough up-front design to enable sufficient understanding within the team, and allowing something to be released to users, and gathering feedback; then performing customer/user interviews, or using other product discovery techniques to validate previous hypotheses and to learn how users actually are using the product. These insights can be relevant (for instance) at the Daily Scrum, as they lead to changing priorities within the sprint, or modifications to design.

It will require a much more agile mindset, but truly maximizes inspect and adapt opportunities, and it's a leaner approach, as it reduces the overhead of hand-offs from designer to coder, and the waste of designing everything before a single line is code, or a users gets to experience the product for real.

-----

An example might help to illustrate my point. Imagine an online shop has a sprint with an outcome-oriented Sprint Goal, rather than just an agreed deliverable. Something like: Increase the average spend of a first-time customer by 50%

Previously this Scrum Team might have aimed to build a new checkout page "as designed", even though we weren't certain what effect that would have on purchases. But by focusing on an outcome, everyone is in a position to assess the success of the initiative.

Sometime prior to this sprint, as ever, the Scrum Team are likely to refine what is coming up next, and the Product Owner might explain that we've noticed a lot of customers are editing their purchases within an hour of making them. The hypothesis is that poor design on the checkout page means new customers are not buying as much as they want, and some of them are correcting this later, but an even larger number of customers do not go to this effort, and so we miss a chance to sell to them.

Already, the Development Team and Product Owner might have ideas on how to solve the problem, and amongst the different team members, it's likely that the UX/UI designers will take the lead on some aspects of the design. Collectively as a team, ideas might emerge quickly, based on more specific hypotheses, and items could be added to the Product Backlog.

Some of these ideas may need to be investigated in advance, for the team to be ready in time to commit to the desired Sprint Goal. In principle, this is like with any refinement, but the specific work might be things like setting up A-B tests on proof-of-concept changes to the checkout page, user interviews, or simply recording mouse and keyboard interactions to better understand customer behaviour.

Once the sprint starts, the team would use Sprint Planning to agree on the above outcome-oriented Sprint Goal, and they might fill the Sprint Backlog with items to cover the first few days of the sprint, plus other items that they expect to complete later, where they think the plan is unlikely to change. They will accept that they're going to learn throughout the sprint, so all plans can change, and they will most likely need to leave enough spare capacity to cope with this uncertainty.

The Sprint Backlog will contain work that coders will focus on, such as releasing changed functionality to production, which can be released early in the sprint, so that measurements can already be taken to see if they're having the expected effect on customer behaviour. Deliberate trade-offs might be made (if they're acceptable to the Development Team), such as implementing a technically inferior solution to allow early release to production, with an explicit plan to make it sustainable later within the sprint. Such a trade-off could theoretically apply to testing, with manual testing being acceptable for now, with an automated test written once we expect the feature to remain, and with no major changes planned.

The Sprint Backlog would also contain UX work. This could mean items from the Product Backlog that do not yet have a design, or sufficient acceptance criteria; but probably also planned experiments, such as new A-B tests to be written or measured, validation of design ideas or released functionality with real or simulated users etc.

It can also include work to repay technical debt taken early in the sprint to facilitate early feedback opportunities, and necessary for the sprint to result in a "Done" increment.

This new way of working might require longer sprints, and will certainly require greater discipline; but even a 4 week sprint with a strong focus on early delivery of value and an outcome that is measured throughout, would in many ways be preferable to several weeks of up-front design, and the first potential value and measurement only happening towards the end of the following sprint.

Also, at the end of the sprint, whether the team only achieves a 20% increase, or overachieves and gains a 200% increase, the Product Owner will be in a strong position to decide whether it is worth investing another sprint continuing the same initiative.