All Best Practices

Backlog, Sprint and User Stories / Tickets

Index Challenge Best Practice
(1) Quality related Tickets are neglected due to short deadlines [1, p. 5, 2, p. 2] Every team member owns the quality of the produced code [3, p. 294]
(2) Insufficiently defined tasks [4, p. 91, 1, p. 5] A User Story should be independent, negotiable, valuable, estimable, small and testable [5, p. 700]
(3) Having an inadequate Product Backlog [6, p. 200, 2, p. 2, 7, 8] Order your Backlog by the highest business impact or use other prioritisation techniques [9, 10, 11]
Offer the team some freedom in letting them create their own process of managing the product Backlog [7]
Create unique identifiers for each Backlog Item [9, 10]
Establish meetings to groom your Backlog every two weeks to maintain your clean / up-to-date Backlog. [12] There, the topmost User Stories of the Backlog will be structured using the value of each item [16, p. 200]
Prepare your Backlog with stakeholders [10]
(4) Having multiple (unstructured) Backlogs [13, p. 83] Use only one prioritised Product Backlog [13, p. 83]
Use only one Sprint Backlog, which ought to be separate from the Product Backlog [14, 9, 10, 13, p. 83]
Create unique identifiers for each Backlog Item [9, 10]
(5) Introducing new requirements or changes to a running Sprint [6, p. 201, 15, p. 11 | 66, 16, p. 163] Rather change scope during a Sprint and with a positive attitude to change, than after the Sprint [15, p. 11]
Analyse team performance with different Sprint lengths and apply the best one to your process [6, p. 201]
Communicate the impact of changes within a Sprint to your customer [15, p. 11]
Meet with the responsible Product Owner and assess the team’s state. After taking the state into account, set the direction and timely details for the new Sprint Planning [15, p. 67]
(6) Software bugs are not being fixed enough or take up too much time within the Sprint [17] Hold sophisticated triage meetings to determine on the share of new tickets to bug fixes [17]
Define the bugs priority through a combination of severity, significance and risk (e.g. project delay) [17]
Every team member owns the quality of the produced code [3, p. 294]
(7) Unsuitable Sprint length [6, p. 201, 15, p. 64, 2, p. 2, 7] Analyse team performance with different Sprint lengths over the course of a few months and apply the one best suited for your process or try iterating to the best Sprint length [6, p. 201]
Let the Scrum Master advocate in favour of lesser Sprint lengths in front of the team [15, p. 64]
The Scrum Master may decide upon the Sprint length given the Scrum Master has extensive experience [7]Offer the team some freedom in letting them create their own process of managing the product Backlog [51]
Create unique identifiers for each Backlog Item [9, 10]
Establish meetings to groom your Backlog every two weeks to maintain your clean / up-to-date Backlog. [12] There, the topmost User Stories of the Backlog will be structured using the value of each item [16, p. 200]
Prepare your Backlog with stakeholders [10]
(8) The team is going to take shorter than anticipated to finish all tasks they committed to [9] Do not deflate your remaining Sprint time [9, 10]
Pull new User Stories into your Sprint [15, p. 12]
(9) The team is going to take longer than anticipated to finish all tasks they committed to [15, p. 73] Do not inflate your remaining Sprint time [9]
The Scrum Master and Product Owner should assess potential consequences of the failed deadlines [15, p. 74]
The Scrum Master may investigate the situation and gather information on why the deadlines were missed to present to the customer [15, p. 74]
The Scrum Master and Product Owner should prioritise remaining Sprint Backlog Items in an effort to maximise the value of the Sprints’ outcome [15, p. 74]
(10) The count of User Stories within the Backlogs is already sufficient for a Sprint [9] Plan another Sprint ahead [9, 10]
(11) Insufficient visualisation of Product Backlog and Sprint Backlog [18, p. 109] Use Information Radiators (regardless of digital or analogue) [13, p. 83]

Communication

Index Challenge Best Practice
(12) Poor knowledge management (e.g. leads to a lack of comprehension of the project or distractions) [15, p. 61, 19, p. 517, 4, p. 86, 20, p. 64, 21, p. 4] Establish knowledge transfer meetings [15, p. 61]
Create timeboxes within the week to share knowledge [15, p. 61]
Enhance already set goals with further details on knowledge transfer [22, p. 49]
(13) No or not enough transparent communication [12] Foster transparent communication though the creation of a “free-to-fail” atmosphere [12]
(14) Customers are not being involved enough [19, p. 517] Let stakeholders take part in some Scrum meetings [9, 10]
(15) Too much or partially unnecessary communication between team members [15, p. 11 | 54-55, 23, p. 97, 24, p. 313] Scrum Masters must moderate meetings [15, p. 11]
Scrum Masters should hold a pre Sprint Planning meeting with Product Owners [15, p. 55]
Do not sacrifice too many resources to the daily Scrum meeting [24, p. 313]
(16) A team member slowly withdraws him-/herself from the others and is difficult to reach [25, 22:33, 15, p. 59, 26, p. 195] Dismiss the team member as he/she is not a team player and the attitude is unlikely to be changeable [15, p. 60]
(17) The Scrum team's surrounding company needs to know an estimate of how much the product will cost in advance [6, p. 200] Use Planning Poker to estimate the requested figures together with the team [6, p. 200, 14, 9]
(18) Interruptions caused by stakeholders [6, p. 201, 15, p. 67, 16, p. 163 | 168, 2, pp. 2-3] Create a timebox for asking questions, ranging from a fixed hour per day to a few hours per week [6, p. 201]
Scrum Masters should prohibit interruptions to the team [6, p. 201, 7]
Flesh out a behavioural plan on how to react to interruptions by the interrupter [15, p. 68]
Reach out to other stakeholders [15, p. 68]
Confront the interrupting party [15, p. 68]
(19) Inadequate progress communication [6, p. 201] Use Information Radiators [6, p. 201]
Install a Burn-Down-Chart [14, 10] (e.g. on the wall) [16, p. 201]
Try to integrate progress visualisation into a project management tool the team uses [6, p. 201, 9]
Visualise the team's velocity [10]
(20) The customer does not provide enough feedback on intermediate results and solely shows interest for the finished product [6, p. 200, 27] Slowly familiarise the customer with Scrum. The customer will normally appreciate the incremental nature of Scrum [6, p. 200]
Implement a customer feedback loop of high frequency [14] especially at the beginning of a project [54, p. 84]
Get the customers’ feedback on your deliverables past every Sprint [14]
(21) Justified dissatisfaction on the customers side during review [15, p. 70] Embrace given feedback and utilise it to improve the next Sprint [15, p. 71]
Create action items from given feedback to use in the next Sprint [15, p. 71]
The Scrum Master may relay given feedback to the team in their next internal meeting [15, p. 71]
Implement a customer feedback loop of high frequency [14], especially at the beginning of a project [54, p. 84]
Get the customers’ feedback on your deliverables past every Sprint [14]
Work on the Product Backlog and product vision together with stakeholders in a special meeting [9, 10]
(22) Unjustified dissatisfaction on the customers side during review [15, p. 71] Accept given feedback and inform responsible employees to cope with the issue before the next review [15, p. 72]
If the issue comes up several times again, the Scrum Master and Product Owner may confront all stakeholders about the situation and its conceivable influences on the project [15, p. 72]
(23) The team has little knowledge as to what the product should look like [9] Work on the Product Backlog and product vision together with stakeholders in a special meeting [9]

Meetings and Events

Index Challenge Best Practice
(24) Hosting meetings, events or ceremonies is not possible for the scrum team [28, p. 129] Use another form of communication (e.g. a dashboard) [28, p. 129]
(25) High level of improvement of Scrum Masters efforts possible [6, p. 201, 4, p. 91, 24, p. 313] Recruit externals to help with hosting retrospectives [6, p. 201]
(26) Sprint Planning tends to be difficult [29, p. 5040] Communicate a single main goal for each upcoming Sprint [9]
Communicate objectives clearly [10]
Only pull as many Product Backlog Items as you are likely to accomplish during one Sprint to create the necessary focus on these tasks [29, p. 5040]
Use the teams velocity as a guideline on the volume of pulled tasks [14, 9, 30, p. 109]
Improve through using past experiences with the team's velocities [9, 30, p. 109]
(27) Punctuality for meetings is a lesser valued attribute within the team [23, p. 97, 4, p. 87, 24, p. 313] Establish consistency (e.g. start your meeting at 8 o’clock sharp) [12, 17]
(28) Ineffective Daily Scrum meetings [17] The team should stand up during your Daily Stand-Up meeting [9, 10, 17]
Establish consistency (e.g. start your meeting at 8 o’clock sharp) [12, 17]
Run the Daily Scrum meeting at the same place every time [31]
Have the same team members on your Daily Scrum every time [31]
Conduct your Daily Scrum within a time-box of 15 minutes to improve focus [31]
Aim to answer only the three main questions (What did I do yesterday? What will I do today? What’s in my way?) and concisely [17]
(29) The Daily Scrum morphs into a status update meeting towards stakeholders [23, p. 97, 31, 32, 0:20] Stakeholders should be updated elsewhere [31]
Aim to answer only the three main questions (What did I do yesterday? What will I do today? What’s in my way?) [31]
(30) The Daily Scrum morphs into a meeting to mainly solve problems rather than to update each other and discuss [31, 32, 0:20] The Scrum Master may moderate the meeting in order to bring attention to the three daily Scrum questions [31]
Dedicate a fixed length of time to problem solving [10]
(31) The Daily Scrum morphs into a gathering around the Scrum Board [31, 32, 0:20] Set your focus on discussions and updates again [31]
(32) Too much nonconstructive feedback is provided while conducting a retrospective [15, p. 69] Focus the teams attention on finding just a single aspect to improve upon instead of multiple [15, p. 69]
Refine given feedback with the team until everyone agrees to around one to three of the most important points [15, p. 69]
(33) Insufficient reflection of the bygone Sprint is being done by the team [6, p. 201, 15, p. 70] Establish regular retrospectives after every Sprint. [12, 33] If Sprints are ≤ 2 weeks in length, settle for a retrospective every second Sprint [16, p. 201]
Try reducing the frequency of retrospectives [15, p. 70]
The Scrum Master may try out different approaches to retrospectives each time [15, p. 70]
“Use the retrospectives as a postmortem meeting.” [15, p. 70]
Utilise remaining time for games or entertainment purposes (e.g. let the team decide on an action item) [15, p. 70]
Aim for fast improvements [11]

Mindset and Interpersonal Relationships

Index Challenge Best Practice
(34) Not considering technical debt and code quality or bugs as a field to continuously improve upon [17] Implement a bug bar [17]
Dedicate time for created bug debt in the next Sprint [9]
(35) Unrealistic expectations or inexperienced guesses regarding the execution of tickets [15, p. 72, 16, p. 162, 4, p. 87] Request the team to give their estimation of the complexity of tasks [15, p. 73]
Abandon the usage of story points. Developers will silently estimate given tasks when committing to new tickets during Sprint Planning [15, p. 73]
Intentionally estimate a higher amount of Story Points to compensate for possibly inaccurate guesses [15, p. 73, 9]
(36) Employees being caught in waterfallish thinking [6, p. 200, 27] Establish meetings to groom your Backlog every two weeks. There, the Product Owner may create new User Stories while being helped by the team [6, p. 200]
(37) Team members working outside of their designated scope (e.g. a Developer takes tasks of a remote working architect) [15, pp. 53–54 | 57 | 65] Physically position the remote working employee more toward the company [15, p. 54]
Get the Scrum Master to intervene within the Sprint [15, p. 65]
Inform higher ranking management [15, p. 58]
Confront said employee [15, p. 58]
Replace the employee if none of the above apply or solve the situation [15, p. 58]
(38) A team member oftentimes needing to be helped by the team to match deadlines [15, p. 55] The Scrum Master should take training sessions on how to accomplish the employees’ work. As the Scrum Master gets involved, the employee experiences higher pressure to improve. [15, p. 56]
(39) The Product Owner is not providing final project requirement documents near the end of a project [15, p. 65] Development may not begin before the final requirements documentation is available [15, p. 66]
Lessen the detailedness of the requirements documentation [15, p. 66]
(40) The Scrum team does not have enough intrinsic motivation to become self-organising, self-examining or empowered [16, p. 168, 11, 26, p. 195, 34, pp. 227-228] Establish maturity assessments to for example examine the continuous improvement of your team [13, p. 84]
Make the team realise their own potential [35, 1:56]
(41) The agile team rejects to continuously improve within the process [25, 23:50, 34, p. 228] Establish a culture that promotes continuous improvement as well as high performance [36, p. 148]

Scaling and Time Synchronisation

Index Challenge Best Practice
(42) Team members are only part-time available, are working on other projects or work remotely [16, p. 163, 4, p. 86 | 91, 2, p. 2, 37, p. 275] Meet twice a week on fixed dates as a substitute for daily meetings [37, p. 276]
Combine Sprint Review, Retrospective and Sprint Planning into a single event [37, p. 276]
Establish rules about communication with remote team members [9, 10]
(43) The team is distributed over multiple locations [38, p. 1532, 39, p. 108] Utilise the daily meeting of all Developers [38, p. 1532]
Product Owners should meet daily [38, p. 1532]
Builds can be automatically generated hourly [38, p. 1532]
Integrate XP practices into the Scrum method [38, p. 1532]
Use Scrum-of-Scrums [39, p. 109]
(44) Scaling Scrum to higher levels (e.g. global) or synchronising teams [16, pp. 162-163, 5, p. 692, 21, p. 4, 36, p. 148, 39, p. 108] Use Scrum-of-Scrums [39, p. 109]
Find a common timeslot for the daily Scrum meeting within the workday of each team [36, p. 148]
Have the maximum team size so that the team “can be fed by two large pizzas” [5, p. 692]
Use tools of communication that allow for videoconferences [13, p. 83]
Establish rules about communication with remote team members [9]
Augment Scrum practices with best practices of Global Software Engineering [40, p. 1137]

Scrum Knowledge and Scrum process

Index Challenge Best Practice
(45) Employees possess inadequate or no knowledge of the Scrum process [25, 23:08, 6, p. 200, 15, p. 58, 1, p. 5, 2, p. 2, 7] If the team was established recently, organise training meetings about Scrum for Managers and emphasise the benefits of having key team members understand Scrum fully [6, p. 200]
Coach concerned team members (again) on agile methodologies [15, p. 59]
(46) Scrum does not provide explicit guidelines regarding the architect of a project [41, 42] The architect may act from within the development team [41]
The architect may act as a stakeholder with an advisory role [41]
Treat the architect as a stakeholder [42, 2:40]
Get the architect involved early into the process [42, 2:40]
(47) Design is no explicit part of the Scrum process. There is only little obvious business value in designing the product [43] Design may find its way into Scrum as extra tickets / stories [43]
(48) Neglecting the architecture of software in long running software projects [43] The development team should design their software to minimise technical debt if no architect is present [43]

Testing

Index Challenge Best Practice
(49) Testing is coming short or neglected fully due to short deadlines [6, p. 201, 3, pp. 294-295, 1, p. 5, 2, p. 2] Complete code development a few days prior to the end of the Sprint and test. Tune these few days according to your experience over time [6, p. 201]
Testing should take place within the Sprint [44, p. 200]
“Testing begins long before the testers start writing automated scripts” [3, p. 294]
Use FitNesse or likewise lightweight test suites [14, 3, pp. 294-295]
Testing should begin on the first day within the Sprint and kept going continuously [3, p. 295, 13, p. 84]
Utilise build-and-deploy systems that run automatically [3, p. 295]
(50) Testing by a quality engineer cannot be conducted within the Sprint [15, p. 68] While the development team is working on Sprint N, let the quality engineer simultaneously test all definitions of done appearing in Sprint N-1. [15, p. 69]
Automate your tests using test suites [14, 45]
(51) Testing in a large project tends to be difficult When handling a large Scrum project, it is possible to separate software testing from the Developers [46, p. 98]
Automate your tests using test suites [14, 45]

Transformation

Index Challenge Best Practice
(52) Less experienced staff endanger the project [15, p. 62, 1, p. 5] Tutor the inexperienced and underline senior employees’ judgements [15, p. 62]
Provide them with “notes, instructions and guidance on how to apply the method in specific settings, contexts, or circumstances” [47, p. 5448]
(53) Measuring agile performance is difficult or cannot be measured by conventional metrics used in non-agile environments [2, p. 3, 48, p. 255] New metrics to use are:
- Break-Even-Level [48, p. 256]
- Velocity [6, p. 201, 14, 9, 30, p. 109]
- Market adaptiveness [48, p. 256]
- Customer satisfaction [48, p. 256]
- Speed to market [48, p. 256]
- Cycle time [48, p. 256]
(54) When transforming into an agile future, the team resists changing their workstyle [15, p. 63, 49, p. 7] Let the team continue their style of work and slowly increase the amount of agile practices in their working routine [15, p. 64]
When transforming, smooth out difficulties and transform without interruptions [35, 1:40]
(55) Two teams each with different management strategies have to work together [15, p. 56] Replace the non-agile management leader [15, p. 57]
Nominate a new middleman that is part of neither team [15, p. 57]
(56) Not knowing what to focus on when starting an agile transformation [50] Prepare a definition of done when starting out on developing a new product [50]
Find and define a suitable Sprint length for your team [50]
Establish a Scrum Board (either physical or electronical) [50]
Prepare your Backlog in advance of your transformation process [10, 35, 0:20]
Let your new Product Owner have enough time on his hands to prepare the Backlog as well as User Stories [50]
Before you begin transforming your team, have the management be trained on agile practices and what these mean for the business [50]
At the beginning, have every team member be trained on Scrum and its practices [50]
Encourage your team towards starting into a new way of working [35, 1:50]
Introduce further processes or roles which work on details such as a technical architecture, a product vision or project milestones prior to the first Sprints’ start [47, p. 5448]
(57) Underestimating the effort to adopt to agile practices [27] Take small steps towards your agile future. There will be some immediate benefits, while others need months or years to show as you work on them. [27]
(58) The surrounding business is not ready for an agile team [25, 22:10, 19, p. 517, 51, p. 24] Establish an atmosphere of tranquillity on the treatment of Developers around the team [16, p. 162]
Create a meeting with the management of the newly created team and define a goal [22, p. 49]
(59) Key members within the team leave or are dismissed [15, p. 61, 32, 0:53] Assign the team another project and hire new employees [15, p. 62]
Suggest another project which suits the team to management [15, p. 62]
If the team's mother organisation is big enough, utilise interns, working students or other budgets to increase headcount [15, p. 62]
(60) Assuming that roles and accountabilities will stay the same [3, p. 294] Readjust your team roles according to the designations you chose for your team members [3, p. 294]
(61) Cynics or naysayers within the team criticise the transformation to new work methods [3, p. 294] Consult experts early on in the process [3, p. 294]
Let experts decide upon the odds of a successful transformation, not your team [3, p. 294]
(62) The Scrum Team constantly needs organisational support [16, pp. 162-163] Hire an experienced coach to guide your staff through the transformation [52]
(63) When transforming into an agile future, it is burdensome to terminate or pass on projects [19, p. 517] Document details about ongoing projects and set a date to pass it on [52]
(64) The Scrum process cannot run perfectly from the beginning [53] Not until after a few Sprints it should be evaluated in what way the changeover had an effect, as challenges are bound to arise during the transformation [53]

Miscellaneous

Index Challenge Best Practice
(65) Technical difficulties [4, p. 94] Use high quality communication software [9, 10]
(66) A lack of trust in the team by the customer by providing a Product Owner [6, p. 200] Use strong arguments for having a Product Owner yourself, who is not provided by the customer [6, p. 200], e.g. technical knowledge
Try to establish a team of Product Owners with the customers’ Product Owner being a member [6, p. 200]
(67) Dependencies on external factors [16, p. 163, 4, p. 93] Create suited visualisations to identify bottlenecks in your process [9, 10]
(68) Only a part of the requested functionality can be delivered by the team due to lack of knowledge [6, p. 201] Testers as well as user interface designers should be introduced to and working within the development team to expand the team’s competences [6, p. 201]
(69) Unreliable estimates [15, p. 12, 16, pp. 162-163, 11, 54, p. 31, 55, p. 22] Commit to fewer User Stories during a Sprint and pull further items if there are free capacities towards the end of the Sprint [15, p. 12]
Order your Backlog by the highest business impact [11]
Use Planning Poker to estimate Story Points with your team [14, 9, 10, 55, p. 22]
Invite stakeholders to estimate Backlog Items together [9, 10]
Frequently update stakeholders on your decisions while estimating [10]
(70) The surrounding company needs to know a cost or time estimate of the product, so a Product Owner estimates tickets in advance and Developers refuse to commit to these tickets [6, p. 200] The development itself should give estimates on ticket complexity [6, p. 200]
Use Planning Poker to estimate Story Points with your team [6, p. 200, 14, 9, 10]
(71) Too much setup time or time consumed by basic tasks that can be automated [13, p. 84] Automate your complete operations work wherever possible [13, p. 84] (e.g. automated builds)
(72) There is no Scrum Master [25, 24:47, 52] Hire a Scrum Master. A Scrum Master is vital to the process [52]