# data[].attributes.body
Business stakeholders to better understand end user stakeholder needs

Clarity as to the difference between business stakeholders and end user stakeholders

More clarity as to what is Scrum and what isn't Scrum

# data[].attributes.body
Provision of templates to document stages of project i.e. barriers, reviews etc.

Stronger feedback loop for stakeholders - including ability to give feedback to dev team in Review

Staff only participate in dev team when their specific knowledge/expertise is required
Staff can be a part of dev team but not a part of every sprint

Providing clear understanding as to the resource need for staff to enable managers to better manage BAU

Ensure stakeholders are more aware of user journeys

Timelines are clearer and better planned

# data[].attributes.body
Wider knowledge of SCRUM across the charity

Staff able to dip out when sections of development is not relevant to them or their knowledge

# data[].attributes.body
Capacity

# data[].attributes.body
Could get around other priorities by planning daily stand up

Difficult for line managers to manage BAU and how much staff time it used

Difficulty explaining MVP principle internally & externally

To be realistic about workload

BAU always gets in the way

SCRUM Masters and Product Owners shouldn't be working on multiple Scrum projects

Need a method of prioritising other work when involved in a scrum project

Dev team being involved in everything caused significant resource issues for rest of org & wasn't always best use of individual team

# data[].attributes.body
Most line managers were accommodating

# data[].attributes.headline
Defining and agreeing roles for project teams, agreeing resources, delivering business as usual tasks alongside being in being in/having staff members in a SCRUM project, 

# data[].attributes.subject
Defining and agreeing roles for project teams, agreeing resources, delivering business as usual tasks alongside being in being in/having staff members in a SCRUM project, 

# data[].attributes.headline
Developing product backlog, prioritisation of backlog, agreeing priorities with stakeholders, project and release timescales

# data[].attributes.subject
Developing product backlog, prioritisation of backlog, agreeing priorities with stakeholders, project and release timescales

# data[].attributes.headline
Story Mapping, developing user stories,  acceptance criteria, sprint communication & transparency of process and projects progress

# data[].attributes.subject
Story Mapping, developing user stories,  acceptance criteria, sprint communication & transparency of process and projects progress

# data[].attributes.headline
Agreeing a sprint goal, planning the sprint, delivery of the product, transparency, testing

# data[].attributes.subject
Agreeing a sprint goal, planning the sprint, delivery of the product, transparency, testing

# data[].attributes.headline
Release of sprint product, ways of giving feedback, incorporating feedback into Product Backlog and sprints

# data[].attributes.subject
Release of sprint product, ways of giving feedback, incorporating feedback into Product Backlog and sprints

# data[].attributes.headline
Sprint reflections, identifying improvements & carrying them forward

# data[].attributes.subject
Sprint reflections, identifying improvements & carrying them forward

# data[].attributes.body
Keep sprints to 2-3 weeks

# data[].attributes.body
Organisation wide education piece on Scrum
And shared understanding of terminology
Engaging right people at right time to get buy-in

# data[].attributes.body
Scrum projects to fit in with/adapt to other BAU/organisational plans and big pieces of work

Scrum comms plans in place for dev team, line managers and stakeholders

# data[].attributes.body
Consistency on who was scrum master (and always understood the problems) for the stand up

Often clashes with other meetings - due to lack of understanding elsewhere in org

# data[].attributes.body
Difficulty timing wise for flex working. Scrum team to choose time

Need clarity on what is/isn't a barrier and whether the SCRUM Master needs to get involved

# data[].attributes.body
Short and efficient

Got everyone together

Good for clarity and accountability

Knowing what is being worked on each day

Good for focus on delivery

Great for communication

Focus on small tasks

Team worked together and shared responsibility

# data[].attributes.body
Practical steps to change

# data[].attributes.body
Honesty about what worked and didnt - allowed for constant improvement

Honesty

Recognising what's good to take forward

Learning from the process

# data[].attributes.body
Stakeholders have good reason to get involved (make the reviews mandatory)

Stakeholders need to be able to feedback in/after sprint to dev team to help steer the next sprint

Ability to invite 250> people to a skype meeting

Incorporate feedback loop which includes giving others not attending the chance to review and feedback

A way to document and save feedback

# data[].attributes.body
Synchronisation with 3rd parties running their own scrum teams

Lack of organisation interest in the projects/process

Feedback at the sprint review

# data[].attributes.body
Plan the review as part of the sprint

To have a pre-review meeting with Product Owner

Could invite all staff to sprint review

The dev team feels under pressure when preparing and presenting at the sprint review

Opportunity to see real time progress

# data[].attributes.body
Regular - stakeholders able to keep on top of what was happening

Ability to broadcast to a wide audience

Good to see progress, milestones achieved along the way

Stakeholders not allowed to question dev team

Transparency of the work that has been achieved

Delivery of the reviews

# data[].attributes.body
The right amount of time per sprint

Perhaps one tool used by all dev teams

pre-sprint Jira training

Moving tasks to "done" in Trello for more transparency

Time between sessions to digest feedback

Time to make revisions - built into process as not everything will be right first time

# data[].attributes.body
Other work can impact on ability to achieve sprint goal

face to face contact to work on tasks together

# data[].attributes.body
Don't have too short sprints

Be realistic about capacity

Sprints need to be flexible ie tasks which are not completed, impact the next sprint

Learnt to use tools such as Jira, Trello and Teams

Need more space to get guidance from others/stakeholders as went from "this is what we are going to to" to "here it was" Things can go off track quickly

Decision making needed to be clearer - lack of understanding by dev team as to their authority. This made is blurred.

Sprint content wasn't completed which squeezed future sprints

# data[].attributes.body
Fast paced
Team given freedom to work together to solve problems quickly and decisively.

Things done more quickly

Quickly prioritise tasks

Sprint goal focuses the team

Dev delivered well and met expectations of Product Owner

# data[].attributes.body
Staff on sprints to be able to focus more on this work

Making acceptance criteria more thorough

Feedback loop for the acceptance criteria

Feedback in sprint review

Respect for user research when agreeing objectives

# data[].attributes.body
Planning meetings very long - impact on other work

Hard to set timescales when other work timescales could change.

More preparation on the Product backlog

Lack of SCRUM knowledge amongst Senior stakeholders

Deciding what to deliver by when, before starting out was inefficient

Understanding of user need and ensuring business goals reflected that

Not clear on process for prioritisation of backlog

Not involving the dev team in the prioritisation of the product backlog

# data[].attributes.body
Acceptance criteria needs to be clear from outset and agreed

Acceptance criteria helps ensure what we develop is right

Difficult for a stand in Scrum Master to get up to speed

Need to spend more time defining criteria to work with stakeholders on PBI

# data[].attributes.body
Clarity on timeframes

Reps from across org took on the product backlog

Team members each know what they need to do within timescales.

Product backlog is a strong way of setting priorities

The autonomy and self organisation of the Dev team

Dev team being empowered by the scrum approach

# data[].attributes.body
Staff to have an understanding of user stories

For everyone in organisation to understand how scrum works and principles & language

Guidance for continuous engagement with stakeholders

Business stakeholders to have an u8nderstanding of user stakeholder needs - business stakeholders should be involved in pre-planning and workshops

# data[].attributes.body
User stories might not have been sufficient representation of need.

Not enough communications during the sprint

Not able to feed back during the sprint reviews - limits feedback

Feedback needed to be recorded better

No follow up provided from the workshop that I attended

Time to feedback to stakeholders

Needed more time at start of project to engage stakeholders

project start was rushed, so not enough time to develop user stories and acceptance criteria

# data[].attributes.body
Acceptance criteria needs to be clear from outset and agreed

Really important to engage as many user stories as possible.

How to balance new ideas against expert refinement

Stakeholders needed to better understand the changes and challenges as they arose

Sometimes the dev team doesn't have the right expertise to make all decisions in an informed way

# data[].attributes.body
Multiple opportunities to learn about progress of project and provide feedback.

Setting clear acceptance criteria provides clarity of purpose.

Creates accountability for deadlines.

Open, wide engagement

More thorough process

Engagement with external stakeholders (they have the best ideas)

Members of staff are able to contribute to different areas

Lots of stakeholders were involved and attended reviews