The Scrum Master serves the Scrum Team in several ways, including:

● Coaching the team members in self-management and cross-functionality;

● Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

● Causing the removal of impediments to the Scrum Team’s progress; and,

● Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

“Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”

Technical debt can be defined as the longer term consequences of poor design decisions. In a sense it’s like any other debt - there ought to be a clear understanding of why it is incurred, and how and when to pay it back. Sometimes it is genuinely thought to be worth it. For example, “poor design decisions” might be made for the sake of expediency. Continuing with an unscalable architecture might facilitate a delivery to a Product Owner which would otherwise be impossible if redesign was to happen now. There will be long-term costs associated with the delay in taking remedial action, because it will become harder to refactor the architecture the longer it is left in place and used. That’s clearly a kind of debt, because we are borrowing time from the product’s future which will have to be repaid with interest. Yet given the advantage to be obtained by making that early delivery, the choice to take on this debt might be considered to be appropriate and worthwhile.

The Product Owner is responsible for placing the most valuable and clear items at the top of the Product Backlog.

The Scrum Master is responsible to train and coach team members on a proactive way and convince them to do the right thing. All other options are either reactive or not self-organized.

6 principles for building trusting and lasting relationships with your stakeholders:

1. Listen to others and seek first to understand before being understood.

2. Have empathy and think in win/win solutions.

3. Set a good example as project manager.

4. Be honest and open about project progress and have the courage to ask for help.

5. Be proactive and take responsibility for your actions.

6. Maintain a positive mental attitude and don’t be afraid to show your funny side.

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts.

Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team.

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Product Backlog refinement is defined in the Scrum Guide as the act of adding detail, estimates and order to the Product Backlog items. Remember that the Product Backlog refinement is an ongoing activity and is not timeboxed.

The Product Backlog is a living artifact which is continually kept up to date with the most recent insights.

We can't really call it "Done" when user acceptance tests (or any other tests) are not done. Therefore, it has to be done during the Sprint.