Convivio Cookbook
  • Introduction
  • Our Business
    • The Convivio brand
    • What do we do?
    • Our work for clients
    • Our Purpose
    • Our Pulse
      • Big Rocks
      • Problems
    • Company Policies
      • Environmental Policy
      • Anti-Bribery Policy
      • Fair Tax Policy
        • Dividends policy
        • 2020 Results and Tax
        • 2019 Results and Tax
        • 2018 Results and Tax
        • 2017 Results and Tax
  • Our Team
    • Help! I'm new. How do I get started?
    • Starting at Convivio
    • Staff Benefits
    • Being a buddy
    • Having a buddy
    • Free-Range Working
    • Convivio Fridays
    • Notes: give & receive feedback
    • Security Screening
    • Submit Expenses
    • Purchases
    • Your home working environment
    • People Analytics
    • Recruitment
      • Help Card: Writing a Person Profile
      • Help Card: Writing a Job Description and Advert
      • Help Card: Publishing a Job Advert
      • Help Card: Reviewing CVs
      • Help Card: Preparing and Conducting Structured Interviews
      • Help Card: Preparing and Conducting Remote Working Interviews
    • Team Policies
      • Security Policy
        • Acceptable Use Policy
        • Business Continuity Management
        • Data Usage Policy
        • Document Access Policy
        • Mobile Equipment Policy
        • Two-Factor Authentication (2FA)
        • VPN Guide
      • Equal Opportunities
      • Grievance Procedure
      • Disciplinary Procedure
    • Taking time off work
      • Holiday
      • Sickness
    • Peer reviews
    • Mental Health
      • Mental Health Training
      • Mental Health First Aid
      • Returning to work
      • Resources
    • Continuing Professional Development
      • CPD Annual Planning
      • CPD Sprints & Scrums
      • CPD Annual Review
      • CPD Annual Retrospective
  • Our Clients
    • Principles For Building New Client Relationships
    • Researching
    • Connecting
    • Nurturing
    • Assessing
    • Learning and Thinking
    • Pre-qualification questionnaires
    • Proposing
    • Agreeing
    • Beginning
    • Inspiration
  • Our Marketing
    • Content Publishing
      • Git Repository Conventions
      • Help Card: Writing a Case Study
    • Brand Guidelines
      • Content Guidelines
      • Branded Documents and Reports
  • Our Tools
    • Infrastructure
      • External Firewalls
  • Internal Projects
    • How we improve our business
  • Client Projects
    • Delivery Launch
    • Delivery Team
      • Convivio People
      • The Coach
      • User Researcher
      • Other Team Members
    • Digital Strategy
    • Discovery
      • Discovery Briefing
      • Discovery Planning
      • Discovery Modules
      • Discovery Findings
      • Discovery Principles
      • Prepare for prototyping
    • Prototyping
      • Inputs to Prototyping
      • Prototyping Objectives
      • Prototyping Inception
      • Prototyping Sprints
      • Prototyping Outputs
    • Build
      • Inputs to Build
      • Build Kickoff
      • User Stories
      • Backlog Management
      • Backlog Scouting
      • Sprint Planning
      • Sprinting
        • Daily Standup
        • Story Lifecycle
        • Design in Sprints
        • User Testing in Sprints
        • Quality Control in Sprints
      • Sprint Review
      • Sprint Retrospective
    • Service Management
    • Digital Service Standards
      • Delivery Methodologies
        • Scrum
        • Kanban
        • Lean
          • Technical Standards
        • Code Quality
        • Testing
        • Automation
          • Security Standards
          • Quality Standards
          • Risk Standards
    • Delivery Governance
      • Steering Group
      • Risk Management
        • Risk Attitude
        • Assessing Risks
    • Delivery Help Cards
      • Help Card - Sprint Planning
      • Help Card - Sprint Review
      • Help Card - Sprint Retrospective
      • Help Card - Product Owner Feedback
      • Help Card - Common Issues
      • Help Card - Slack
      • Help Card - Github
      • Help Card - Trello
  • Our Recipes
    • Convivio Classic Cocktails
      • Ingredients
      • Tips and Techniques
      • Martini
      • Negroni
      • Manhattan
      • Old Fashioned
    • Potage Dubarry (or, creamy cauliflower soup) with spiced green pepper
    • Roasted Sweet Potato in a Herb and Nut Salad, with Maple Chilli Dressing
    • Aubergine Curry
    • Vegetarian Paella
    • Easy Ice Cream
Powered by GitBook
On this page
  • Daily Standup
  • Driving Quality
  • Over or Under Estimating
  1. Client Projects
  2. Build

Sprinting

The sprint a is two week period of activity by the delivery team to work on and deliver the stories taken into the sprint. It’s the job of the Product Owner and Scrummaster to keep noise and interruptions away from the delivery team during this time to allow them to focus on the priority stories.

During the sprint members of the delivery team will select stories from the sprint backlog. As stories are worked on their progress is recorded in our delivery tool (usually Rally or Pivotal or something similar) so that we can clearly report whether or not the sprint is on target.

Daily Standup

Each day the team, together with the Product Owner will hold a daily standup. This is a meeting, time boxed to 15 minutes. During this short meeting each of the delivery team will briefly discuss what they’ve done since the last standup, what they have planned for today and they’ll raise any blockers or risks that need to be addresses. This meeting keeps the Product Owner up to date and it provides a natural break to raise any concerns or risks that might be affecting the sprint. The sooner we discuss an issue the sooner we can resolve it and the less chance it has to grow into something more difficult to tame.

At the end of the standup we’ll hold a separate meeting for any issues that need to be resolved and only involve those who need to be involved. Let people focus on delivering the sprint whenever possible.

Driving Quality

Before a story can be marked as complete it has to go through various tests and checks to make sure that it meets certain criteria:

  • Has the story been completed in the way expected by the Product Owner?

  • Is it free from bugs?

  • Does it function and display correctly on the array of desktop and mobile platforms and browsers?

  • Has the code been well written and does it meet our standards and any other standards agreed?

To drive this quality we use a series of tools and people to carry out our QA:

  • All code is peer reviewed to make sure it meets the required quality and security standards

  • The client provides UAT to test the stories to make sure that the functionality, content and display is correct (cross browser testing)

  • The “definition of done” is a list of requirements that all stories must meet

  • Continuous integration requires developers to check code in regularly for automated testing, early detection of problems and regression testing

  • Usability testing

If a user story doesn’t pass the tests then the failure is recorded and we pass that back to the delivery team to resolve and it goes back into the develop-test cycle until we’re happy that it can be deployed.

Over or Under Estimating

Estimates, by their very nature, are not exact. What we're looking to do with user story estimates is give ourselves a reasonably accurate estimation of the work we can expect to complete in a sprint.

If, at the end of the sprint, not all user stories are finished (done-done) then this doesn't mean that the sprint has failed. What this does show is that we discovered a story to require more effort than expected, that a module didn't provide the input we expected or that there was some other influence that affected the sprint.

If we have incomplete stories at the end of a sprint then we push those back into the backlog and it's up to the Product Owner whether or not they're priority stories for the next sprint. What we need to do is understand if there were particular reasons why our estimates were not accurate and take action to avoid those happening again in future.

When you're delivering work on such a regular basis it quickly becomes apparent just how transparent the process is. People need to understand that when a sprint "slips" we discover that very quickly and are able to adapt and fix any issues very quickly.

In reality, experience shows us that our accuracy over the course of a longer term assignment improves as we understand more about what we're delivering. The velocity also tends to increase as the team becomes more efficient. Tracking the estimates and velocity over time show that the agile approach delivers consistently, at a high velocity, with regular improvements and with the high quality we should all expect.

PreviousSprint PlanningNextDaily Standup

Last updated 7 years ago

Next stage:

Sprint Review