When an item that comes from the Product Backlog eventually gets moved to “Done” - what does this mean?

The definition of done tries to make sure that everyone in the team has a shared understanding of what “Done” means, improve transparency and to enable the team to decide if work has actually been completed.

The definition of done will evolve or expand depending on how mature the team is and the team improving their criteria to improve the quality of the product.

Examples of what items may make up the definition of done could include

• The code has been peer-reviewed

• The code has been deployed to test environment

• The feature has been tested against acceptance criteria

• The feature has passed regression testing

• The feature has passed smoke testing

• If required, documentation has been done

• The feature has been checked by the UX designer

• The PO is happy with what has been developed and demoed

Some teams who run more of a hypothesis development backlog may even add items to their definition of done including

• Is the feature doing what we predicted with live users

• Is the data we are recording from users backing up our hypothesis

If the feature on the production environment is not doing performing as predicted, the team may consider it not done and there for more work has to be done to get the desired results.

Essential Items

• The Product Development Team

• The PO

• The SM

• Snacks

• Tea / Hot Chocolate

Structure

• PO Update

• Definition of Done (D.O.D)

• Velocity

• Proposed Sprint Backlog

• Sprint Goal

PO Update

This is the kickoff for the meeting and starts with the PO setting the scene.

• 10 mins max

• Feedback from stakeholders - e.g. How the product is doing, discussions with them, support issues

• Updates on the roadmap if anything has changed or how we are doing

• Whishes and desires for this sprint - This is a big hint and useful to give ideas about the sprint goal

• Allow members of the product development team to ask any questions around the bigger picture or the product, vision etc

Definition of Done (D.O.D)

This section is used to clarify with the team exactly what they consider done to be. It is important to discuss what done means as if it changes it might affect how much work the team can bring into the sprint. I normally do this by asking each team member what items are on the D.O.D list until they agree all items have been listed.

The result is the whole team (Product Owner, Product Development Team and Scrum Master) all agree on what done is so when tickets are moved to the done column, everyone knows what this means.

Velocity

The goal of this section is to agree roughly on how much the team can commit to and normally follows this format

• Close the current sprint in front of the team so they see items completed and leftovers and the burndown.

• Open up the velocity chart so the whole team can see the teams velocity

• Calculate an average from the last few sprints - 3 is normally enough

• Check for holidays, training or other events that may take members away from the sprint as a result, the velocity needs to be adjusted

• Agree on an estimated number of story points to aim for the sprint being currently planned

The outcome of this section is to have a rough number for looking at the proposed sprint backlog.

Proposed Sprint Backlog

The first part of this section involves

• Identifying the leftovers from the last sprint

• The PO and the team deciding if the leftover item should be added into the next sprint and if so,

• Estimating again the amount of effort and adding the issue into the sprint by dragging the item from the backlog into the proposed sprint backlog

After all the leftovers have been discussed, the next section is to look at the top of the backlog that is ready for planning and for each

• PO read the story out loud to other members of the team

• Any assumptions?

• Any dependencies?

• Check the acceptance criteria, if there is none, write it there and then with the team.

• Allow the product development team to discuss how to implement the item

• Discuss the issue

• Ask the question “Does everyone understand the issue, does anyone have any questions”

• If the issue has not been estimated - estimate the issue

• If the issue has already been estimated, estimate again if there has been substantial discussion around how the implementation will work or confirm the team are happy with the current estimate.

After the issue has been discussed, the PO can drag the issue into the proposed sprint backlog. This process will carry on until the number of story points roughly matches the amount discussed during the velocity section.

Commitment (Now called Forcast)

When the proposed sprint backlog is full, the team and the PO need to take a moment to consider what has been added. If the PO wants to add more then they need to negotiate with the team either by removing some items already added or if the team feel comfortable to take on more.

During this time its useful to

• Make sure the highest priorities are at the top of the sprint backlog

• Encourage the team to think about their plan of attack for the sprint and allow them to discuss it.

• Make this visual so the entire team is looking and viewing the proposed sprint backlog

• Allow them to focus in silence if need be, ask prompting questions “How do you feel about this” - challenges are ok!

Once agreed, the final thing left is the Sprint Goal

Sprint Goal

The idea of the sprint goal is to provide focus to the team during the sprint and act as a constant reminder about what they are working towards.

The initial idea of a sprint goal comes from the PO update however the sprint goal should come from the team itself using a consensus-driven approach.

Once a goal has been decided by the team, to double check if the goal is realistic, the team can vote on how they feel about it by simply raising a hand and

• Thumbs up for its a good and achievable sprint goal

• Thumbs halfway - not sure or a bit nervous that the goal is more of a stretched goal

• Thumbs down - Sprint goal is too difficult or ridiculous - in this case, the team should revisit the sprint goal and then vote again.

Print the goal, stick it on the wall, GO GO GO!

Key Facts / Findings

A quick summary of a few findings from the report

Reasons For Adopting Agile

• Accelerated software delivery

• Enhanced ability to manage changing priorities

• Increase productivity

Benefits of Agile

• Ability to manage changing priorities

• Project visibility

• Business / IT Alignment

Agile Methodologies Used

• 56% Scrum

• 14% “Hybrid”

• 1% XP

Agile Techniques

• Daily Scrum

• Iteration planning

• Retrospectives

Engineering Practices

• Unit testing

• Coding Stadnards

• CI

• Refactoring

How Success is Measured

• Customer satisfaction / User Satisfaction

• Business value delivered

• Velocity

Challenges Adopting and Scaling

• Organisational culture

• Organisational resistance to change

• Lack of management support and sponsorship

A pretty good self-training series covering the Scrum ceremonies and backlog refinement with a few quizzes

http://scrumtrainingseries.com/

Advantages

• Avoids bank holidays

• Avoids common work from home days e.g. Mondays and Fridays

• Time after sprint review for POs to adjust backlog

• Time after sprint review and retrospective for the product development team to tidy up loose ends before planning

Despite a moment towards thinking of software as an experiment, running hypothesis based experiments and having a position of humility when developing software, many organisations, stakeholders, teams and project managers still fall into traditional predictive approaches and as a result, they want to know the date of when something will be delivered.

Traditional vs Agile

In traditional project management approaches, the scope is fixed with a lot of planning up front and then resource management is used to try and deliver the scope within the time set.

There is lot’s of evidence this does not work e.g. Brooks law and that planning up front doesn't deliver value, soon enough hence the rise of Agile frameworks and that when working with knowledge work, big upfront planning is very hard to do.

So in Agile framework, the traditional triangle of constraints is turned upside down so that the scope is flexible but the resources and time are fixed which we can see through agile promoting small, stable and dedicated teams which are funded for longer periods.

Empirical Process Control

Scrum and other agile frameworks are built on empirical process control, basically, we look at what has happened in the past to predict the future and one of the ways Scrum uses empirical process control is a teams velocity.

Velocity

Most teams use relative estimation, for more details see: Relative Estimation using story points.

After sprint planning, the product development team have a sprint forecast or commitment which is the number of story points they think that they can deliver during the sprint.

Velocity will naturally fluctuate for various reasons such as holidays, sick leave, tasks more difficult than expected etc.

At the end of the sprint and after the review, items that are not done are returned to the top of the backlog for consideration for the next sprint.

In the diagram below you can see

• Committed Story Points - the number of story points the team thought they could do for the sprint

• Complete Story Points - the actual number of story points the team manage to get delivered.

So how does this work in predicting when something will be delivered?

Predicting the date

In order to predict “when something will be done” we need to know the following

• Average sprint velocity - normally last 3 or 4 sprints

• Estimates from the product backlog

• Scope / Date

Average Velocity

To get the average velocity, most teams look at the last 3 sprints. From the diagram above we can see that the team did

• Sprint 12: 175 SP

• Sprint 13: 50 SP

• Sprint 14: 15

So for the teams average velocity its 175 + 50 +15 / 3 = 80 SP

Product Back Log (PBL)

Let’s presume that the team have already done some story mapping and created all the user stories required for a feature and we want to know when that feature is likely to go into production.

In the example below, we have created all the stories required for the new feature: Search Interface. We can see in the PBL below that there are a lot of stories for the feature with the total of 115 story points required to deliver the feature.

Two Planning Scenarios

There are 2 scenarios for planning

1. Fixed Date - here the only compromise is with scope

2. Fixed Scope - A date is predicted based on the product backlog estimates and teams velocity

Fixed Date

In this scanerio, we know

• The date that something has to go live

• The number of SP Required to deliver the new feature: Search Interface

The stakeholders have decided that the new search interface feature must go live on X date.

So we know that

• The Search Interface feature requires 115 story points in total

• The average velocity of the team is 80 story points in a 2-week sprint

• In order to complete the work, we need at least 2 sprints

Luckily, the date given by stakeholders is after 3 sprints, so the team will probably be able to deliver the feature in time

However, what happens if the date given by stakeholders doesn't allow the team enough time based on the velocity and estimations given.

In the scenario, our estimates and team velocity mean we will not be able to deliver everything in the scope required in time.

We know from the Agile triangle of constraints, that in a fixed date scenario, the only option here is to reduce the scope in order to try and deliver some of the features on time.

It has been proven from various Chaos Reports and studies that actually most features in software are not required or not used so a minimum viable product might be the solution here.

A Product Owner would have to go back to their backlog and work out what to prioritise based on what is not providing enough value and reduce the scope of the feature to deliver it based on the fixed date

Fixed Scope

In this scenario, we know

• The number of SP Required to deliver the new feature: Search Interface

The stakeholders would like to know when this will go live

So we know that

• The Search Interface feature requires 115 story points in total

• The average velocity of the team is 80 story points in a 2-week sprint

• In order to complete the work, we need at least 2 sprints

In this case, the Product Owner can communicate to stakeholders that it's estimated the team can deliver the Search Interface feature at the end of sprint 2.

Some teams will fall into a nasty habit of trying to plan everything up front to try and predict the date successfully, however, this is very difficult and also considered a waste.

https://vimeo.com/169914142

Key Points

For Innovation

• Autonomy

• Mastery

• Purpose

Management and Organisational Structure

• Out of date

• Organisation structure not suitable for the creative economy

3 useful Lean Concepts

• Workers decide how to do the work

• Focus on continuous improvement

• View value from the customers perspective

Scrum

• Lean + Complexity science

• Builds on and incorporates Lean concepts

• Small, high performing cross-functional teams

• Incremental product development

• Severt leadership role

Future

• Lean Startup

• LeanUX

• Anti-fragile organisation structures

• Evolutionary purpose

• Wholeness

Applicable

Don Wells defines XP as appropriate for use when

• Working with dynamically changing software

• There are risks with new technology

• Working with small, co-located development teams

• Technology being used supports automated unit and functional tests

XP Framework

The XP Framework has

• Values

• Practices

• Roles

• Lifecycle

Values

5 Values of XP

• Communication - between one team member to everyone else, face to face discussions with the aid of a whiteboard

• Simplicity - whats the simplest thing that will work to avoid waste

• Feedback - Constant feedback helps identify areas for improvements, revise practices and helps with simple design

• Courage - Courage to raise organisational issues, stop doing something that doesn't work and try something new, accept and act on feedback even if difficult to accept. Also applies to the XP practice of pair programming

• Respect - required to communicate with each other, accept feedback and work together to identify simple design and solutions

Practices

The following are the original practices of XP

• The Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40-hour week

• On-site Customer

• Coding Standard

Second Edition Practices

Sit Together

Face to face communication, team sit together, remove barriers, osmotic communication

Whole Team

Functional group with all the skills for a product in a single team

Informative Workspace

Support face to face communication and allow people to have privacy

Energised Work

Knowledge work requires focus and no distractions. Physically and mentally able to focus.

Pair Programming

Software development when two people sitting at the same machine. Two brains and four eyes are better than one brain and two eyes and there is a continuous code review which reduces the feedback time.

Proven to

• improve quality

• Solve problems quicker

• Creates less code to acomplish the same solution

• Doesn't take twice as long

Stories

Describe what the product should do in terms meaningful for customers and users.

Weekly Cycle

A week-long software interation. The team meet on the first day and reflect on what has been done and plan for what to do for the next week with the goal of running tested features that realise the stories selected.

Quarterly Cycle

Similar to release planning. The customer provides the plan for the features desired in a quarter to provide the team with “a view of the forest whilst they are in the trees”

Slack

Adding of low priority tasks and stories into weekly and quarterly cycles that can be dropped if a team falls behind on more important tasks.

10 Minute Build

Automatically build the whole system and run all of the tests in less than 10 minutes. Encourages teams to automate the build process to run all tests. This is supported by continuous integration and test first development.

Continuous Integration

Code changes are immediately tested when added to a larger code base with the benefit of catching any integration issues sooner.

Most teams take the approach “If it hurts, avoid it as long as possible”. Practitioners of XP suggest “if it hurts, do it more often”.

Test-First Programming

Normal Path: develop code -> write tests -> run tests

Test-First Programming Path: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat

Incremental Design

Do a little bit of work upfront to understand the wider breadth and go into specifics of the design when you deliver specific features. Refactoring has been integrated into the principle.

Roles

Customer

• What should the system do - features

• How do we know when the system is done - acceptance criteria

• How much do we have to spend - funding and business case

• What to do next - order to deliver features

Assumed to be a single person, however, in reality, this is often a group of individuals that are required to give the team all the business related information they require.

Developer

Everyone on the team except other defined roles is classed as a developer. A developer is responsible for realising the stories identified by the customer.

The Tracker

Some teams may have a tracker or it is a developer who fills this role. The role is to keep track of relevant metrics defined by the team as important to identify areas of improvement e.g velocity and changes to velocity

The Coach

Help apply, coach and mentor teams on XP.

Lifecycle

XP has a weekly and quarterly cycle.

First - the desired results of the project are described by having customers define a set of stories and for each story that's created, the team estimates the size of each story.

This size estimate, along with relative benefit as estimated by the customer can provide an indication of relative value which the customer can use to determine priority of the stories.

If the team identifies some stories that they are unable to estimate because they don’t understand all of the technical considerations involved, they can introduce a spike to do some focused research on that particular story or a common aspect of multiple stories. Spikes are short, time-boxed time frames set aside for the purposes of doing research on a particular aspect of the project. Spikes can occur before regular iterations start or alongside ongoing iterations.

Next, the entire team gets together to create a release plan that everyone feels is reasonable. This release plan is a first pass at what stories will be delivered in a particular quarter, or release. The stories delivered should be based on what value they provide and considerations about how various stories support each other.

Then the team launches into a series of weekly cycles. At the beginning of each weekly cycle, the team (including the customer) gets together to decide which stories will be realized during that week. The team then breaks those stories into tasks to be completed within that week.

At the end of the week, the team and customer review progress to date and the customer can decide whether the project should continue, or if sufficient value has been delivered.

• Not using absolute units or time

• Comparison or by grouping items of equivalent difficulty

• Establish baselines from the product backlog

For Planning

• Product Owners operating mainly from strategy down to iteration

• Scrum Masters more in the day to day and iteration planning but supporting all layers

• Product development team supporting all layers but mainly on the release, iteration and day.

Layers

Product, Portfolio, and Strategic planning

• Product Owners looking further ahead than release planning to the evolution of the product

• Portfolio Planning - selection of products that will best implement the vision decided by strategic planning

Roadmap

• Where the product is going

• Can be hypothesis driven or for validated learning

• Can be used to gain consensus / facilitate stakeholders

• Owned by the Product Owner

• Few more details here https://hee-tis.atlassian.net/wiki/spaces/PS/blog/2019/01/18/1019248683/Roadmapping

Release

• Consider new user stories or release of the product or system

• Try and work out scope, schedule, resource

• Normally there is a release plan, updated inline with the roadmap

• CI/CD challenging this idea

Iteration Planning

• Start of each iteration

• Sprint planning

• Product owner identify high priority work

• Planning with the Product Development Team

Daily Planning

• Inspect and adapt on a daily bassis

• Often done with a daily Scrum

More complex Version

Simpler Version

Agile Mind Set

• Owned by the Product Owner

• Themes

• Kept up to date

• Simple

• Actively collaborate with stakeholders

• Based on product vision

Tools

Prodpad

• Roadmaps

• Ideas

• Customer feedback

• Portfolio management

• Jira integration

• Unlimited viewer accounts

• Export to PDF

• Simple 3 column structure

• 99$ per month - 3 Admins

Roadmunk

• Views / swimlanes

• Jira integration

• Planning view

• Collaboration

• Export to HTML, URL, PNG

• Supports dates/details

• Basic plan - $19 per month - limited to 1 user

• Sharing only supported by the buiness plan - $49 per user per month

Jira - Next Gen Projects

• Creates Epics in Jira

• Doesn't really support themes

• More like a Ghant chart

• Able to filter by status

• Able to share by link - would need to give users access?

• Only available in next-gen Jira projects - limited workflows and scrum reporting

Trello

• Free

• Can do a 3 collum approach similar to prodpad

• Permissions - Trello Business class - 9.99$ a month per user

• Trell Business supports observer role - still can view comment and vote on cards but cannot move, edit or change settings

• Exporting / sharing - Screenshot?

• There are add ons e.g. https://elegantt.com/ #DeathToGanttCharts

• Trello uses Trello for their own roadmap: