How Project Science apps support Agile Ways of Working

Agile is an enormously successful methodology, made famous by the Agile Manifesto.

There are many books on agile, and substantial documentation on the internet. The language and exact wording varies, but the broad principles remain constant, and it is those principles that this article refers to. Agile is very effective at managing change, because it considers change as part of the process, not as an adjunct to the baseline, which is what occurs in more traditional planning.

This article covers three broad process areas, and for each, describes how Project Science apps assist:

• Sprint Execution
• Sprint Quarterly Planning
• Kanban Execution

This initial version covers the first process area.

Sprint Execution Process

We assume a nominal team with these roles:

1. Product Owner (sometimes also called the Product Manager) - responsible for defining the desired outcome, and assessing the delivered solution against that desired outcome; the product owner is not expected to get involved in the technical details of the solution, because their focus is the ‘what’, not the ‘how’
2. Scrum Master (also known as the team lead, technical lead, project manager or Lead Business Analyst) - responsible for leading the team to the desired outcome, collaborating closely with the product owner
3. Developers (typically 2 to 5) - responsible for scoping the work, implementing and testing the solution, to ensure the desired value is delivered on time

A typical two week sprint can look like this (the exact details will depend on your chosen ways of working):

1. Sprint Planning

Objective

• Establish a clear plan for the upcoming sprint based on the product backlog and any other relevant information

When

• Working day 1; the Sprint planning and Kick off meeting takes place on a Wednesday mid-week; this gives preparation time, and ensures the sprint finishes well before the weekend

Who

• The whole team; meeting led by the Product Owner and Scrum Master

Inputs

• Product backlog (also known as a ’todo’ list)

Steps

• Review the product backlog and identify high-priority items for the upcoming sprint
• Take into account the results of the previous sprint and any new information that has become available
• Estimate the effort required for each item and prioritize them based on business value and complexity – team do this.
• Plan the sprint goal and create a sprint backlog
• Schedule regular check-ins with the team during the sprint to review progress, address any issues, and adjust the plan as needed

Questions asked - with Project Science App support

• How long will this task (or sub-task/issue/bug/epic) take? Predict
• How many story points might this task require? Predict
• How risky is this task? Predict
• Has this task been done before? Knowledge
• Are we duplicating work - is there another ticket for the same thing? Knowledge

2. Daily Stand-up

Objective

• A daily check in with the team, to ensure that all work is on track and for the team to raise any issues or concerns

When

• Working days 2 to 9

Steps

• Each day, the team should attend a daily stand-up meeting, where they will report on their progress from the previous day and the work they plan to accomplish that day
• The Scrum Master or Product Owner may also provide updates and reminders of upcoming events
• This is an opportunity for team members to raise any issues or concerns and get support from their peers
• Update the backlog if new tasks come to light
• If new tickets added to scope, replan the sprint with Product Owner input

Questions asked - with Project Science App support

• Can we accommodate this new task in the sprint; how much work is it? Predict
• Has was this task done before? Knowledge
• What are the risks in this task? Knowledge
• Are we duplicating work - is there another ticket for the same piece of work? Knowledge

3. Sprint Review

Objective

• Review the work completed during the sprint and obtain customer feedback.

When

• Day 10

Steps

• Review the work completed during the sprint, highlighting successes and identifying areas for improvement
• Give a demonstration to the Product Owner; receive feedback
• Adjust the backlog
• Celebrate the achievement of the sprint goal with the team, acknowledging their hard work and accomplishments
• This is an opportunity to reflect on the successes of the sprint and look forward to future challenges

Questions asked - with Project Science App support

• How accurate were our estimates? Predict
• Has our knowledge base updated? Knowledge

4. Sprint Retrospective

Objective

• Operate continuous improvement

When

• Day 10

Steps

• The team should conduct a retrospective of the sprint, discussing what went well and what didn’t, and identifying actions to improve future sprints
• The Scrum Master or Product Owner may facilitate the discussion and capture key takeaways for implementation in future sprints
• Reflect upon the sprint process and identify actions to improve future sprints.

Questions asked - with Project Science App support

• How accurate were our estimates? Predict
• Has our knowledge base updated? Knowledge

5. Backlog Refinement

Objective

• Update the product backlog throughout the sprint, tracking all proposed changes, new issues emerging and new feature requests.

When

• Days 1 to 10

Who

• Led by the Product Owner and Scrum Master

Steps

• As work is completed during the sprint, the team should refine the product backlog by updating item descriptions, estimating effort, and prioritising items based on business value and complexity
• The Scrum Master or Product Owner may also conduct backlog refinement sessions with the team to ensure the backlog is up-to-date and relevant

Questions asked - with Project Science App support

• How long will this task (or sub-task/issue/bug/epic) take? Predict
• How many story points might this task require? Predict
• How risky is this task? Predict
• Has this task been done before? Knowledge
• Are we duplicating work - is there another ticket for the same thing? Knowledge