>> First, you want to understand the business goals.
If you're not making money, if you're not responding to where the business
needs to grow and to the culture that the business is promoting,
then the solution might be the wrong one.
Second, you want to understand engineering.
The technologies, which makes the ideas come to life.
So without understanding where the technology's at and
what the team is able to deliver, it kind of doesn't matter.
That's it.
So we covered the business perspective and then we covered the technology.
What's missing?
What do you think is the third perspective?
>> The users?
>> That's right.
If there's something that's important in design solution, it is who it is for.
The designers and the whole team need to understand who are the potential users
and what are their needs?
When you circle problem in this manner and you look at it from all
perspectives, business, technology, design, you're creating a more
holistic approach, so that the solutions that come have wisdom to them.
That they're not rushed, that they're better targeted.
>> And what would you say is the most important thing in this stage?
>> I think in this stage, it's important to hear different perspectives.
If you are over focusing on one and not the other,
you might have a solution that's lopsided.
So in sprint, we try to be balanced in the beginning and hear from everyone
who'll be involved in making the product or who'll be involved in approving it.
If you're in a large company,
this may be the director of the product and the director of engineering.
They represent the business and the technology.
Similarly, the user researchers or the marketing and sales teams.
Now, if you're in a startup,
you might not have a person representing every single perspective.
>> You could be the single person who represents everything.
>> You could be the three things, right?
>> Right.
>> In a startup, you often are wearing all these different hats.
So, it's useful to consider and pause.
Even if you're one person or
even if you are small team that doesn't have diversified roles yet,
what are the perspectives on this problem as looking in it from
a business perspective, there's one set of issues that they're important.
Those are about the metrics, the goals, the revenue.
Looking in from a technology perspective,
there's another set of problems.
That is generally, what is the code able to do?
What are the features that are being developed?
What's available to outsource or what APIs are available to bring in?
And then from a design perspective,
it's about what are the user needs that you want to address?
When you look at it from these three perspectives,
even if you have a small team, you're helping people stretch their minds.
They're really opening up, so that they can consider and
not miss out on a good idea.
>> Right and what could go wrong in this stage?
>> Oh, that's a great question.
Often, I see teams take a very long time in this stage.
If the team doesn't know each other well, this may be a rare opportunity for
them to start talking to each other and they're so excited to learn from each
other that the stage can drag on and take two or three hours.
The goal of the sprint is to understand, but then quickly move towards the other
stages in which people are defining a strategy and starting to make things.
So what could go wrong is the team can spend too long in this stage.
>> So they could be circling around until they understand and
never to get to an understanding.
>> What could go wrong is they could be like really circling.
Another thing that could go wrong, which is actually a chance for
something to go right is that the challenge might be improperly defined.
Sometimes people who are beginners in the art of being a sprint master,
approach the challenge in a very specific way.
And when they offer to the team, they learn that actually the team has
a different need and there's something else that's more important to solve.
That is a mistake that's easier to correct in the beginning
of this program and not during this phase.
But if a sprint leader finds themself confronted with a team that says,
we should be solving something else,
it is a great opportunity to seek to understand.
Open your ears and help your team agree on what is the right thing to do,
quickly.
>> Very cool.
So what I hear from you is that the basic of these stages to understand.
To understand the business, to understand the technology and
to understand your users.
>> That's right.