Sheila's Blog

This is an informal meeting that lasts about an hour for a week long Sprint.  There are no powerpoints, presentations, speeches or lectures.  The purpose of the meeting is for the team to show fully completed backlog items to the Product Owner.  The team can only demonstrate working software.  Incomplete software is not shown.  The tasks that aren’t completed are moved into the following Sprint.

The Product Owner gives feedback to the team for each task.  This includes whether the working features satisfy the requirements that were given and any feedback that should be taken into account for future requirements.  The Product Owner can also comment on whether the team has achieved an optimal velocity.  At the end of the meeting the scrum master confirms the date for the next Sprint Planning session and the next Sprint Review.

The purpose of the meeting is so that the Product Owner can inspect the work done and accept or reject it.  This makes everyone clear on what has been achieved in the Sprint and allows all team members to adapt according to the feedback for the next Sprint.  The resulting team velocity for the Sprint that has just ended is added to the Sprint Backlog report which is available for everyone to refer back to eg. on a wiki.

Tags:   scrumNo Comments.

This is a daily meeting for the whole team to collaborate, organise the work being done, identify impediments and check the progress being made.  During the meeting the team updates the sprint backlog with the number of hours remaining for each task (and maybe the hours already spent).  From this, the burndown chart is generated.  It’s important for the progress being made to be highly visible to everyone.  It’s not mandatory for the Product Owner to attend, but the team must update the Product Owner as soon as possible if it can’t deliver on the work it committed to.  The backlog can be added to/edited/deleted from with the Product Owner’s agreement in this case.

The format of the meeting is for each team member to state what work they’ve done since the last meeting, what work they plan on doing before the next meeting, and what impediments they have.  This allows the team to synch up and be aware of the work that is doing done as a whole.  The updates provided by each team member don’t include technical details or dependencies.  If there is something technical that needs to be discussed, any interested parties should stay back if necessary.  If a team member has completed a task, then this is the time to select a new task to work on.

At the end of the meeting the Sprint Backlog and burn down chart have been updated.  This makes progress highly visible and public.  It focuses the team on what work is left to do so it is easier to monitor whether the sprint goals will be met.  The Scrum Master keeps note of any impediments and works to resolve them.

The general rules for the standup meeting are that it should take place in the same location and at the same time every day.  The meeting must start on time and some teams apply penalties for being late.  The meeting is time-boxed to 15 mins and everyone should stand to encourage people to keep things brief.  Anyone can attend, but only the team members may speak unless invited to.  The team members answer three questions -
What have you done since yesterday?
What are you planning to do by the end of today?
Do you have any problems preventing you from accomplishing your goal?

In a situation where the team has trouble meeting their committments each Sprint, it can be useful to add a 4th question – “How confident are you that the team will achieve the Sprint goals?”  This encourages the team to speak up if anyone is worried that work is not progressing at a sufficient pace, or there’s an unforeseen impediment.  The team should always be aware that they are being judged as a team, not individuals, so the team a whole fails if committments are not met.  They must work together to succeed.

Tags:   scrumNo Comments.

The Sprint Planning meeting is used to identify the work for a Sprint, and prepare the Sprint Backlog which details the estimates of time needed to accomplish each task.  The Product Owner prepares for the meeting by making sure the Product Backlog is up to date (add/describe new requirements, prioritise the items and make sure the estimates for each story are current).  The planning meeting can last about 2 hours for each week of a sprint – roughly half the time for discussing requirements, the remainder to break stories down into tasks.  At the end of the meeting, the team has committed to completing the items in the Sprint Backlog.

The team identifies their capacity based on the number of people available, less holidays etc for the sprint.  The wrong workload will cause the team to burnout.  About 60% utilisation is normal.  Starting with a gross capacity of hours, about 10% should be allocated for the scrum process (which will reduce over time).  Keeping the product and sprint backlogs up to date can take another 10%.  Maintenance of existing code should be allocated some time.  Finally a buffer should be applied that will be reduced over time as the team starts to estimate more accurately.

The team picks the top priority stories from the Project Backlog that it (without influence from the Product Owner) believes can be completed in the sprint, and drafts a Sprint Backlog to work from.  The teams asks questions of the Product Owner for each story – possibly agreeing acceptance tests/test data or UI designs as part of this so that everyone is clear what the criteria are for the story to be accepted as completed.  The team then discusses and breaks each requirement down into tasks and volunteers or assigns the tasks.  Tasks should be a maximum of 1-2 net days work.  This is to make progress clearer on a daily basis.  The team stops committing to tasks if the availabilty is consumed, or the knowledge/skill set of the team members is insufficient.

If uncertainty is high, dependent tasks in one sprint should be avoided.  Task estimates should not be padded – the buffer takes care of this.  The team is going to be measured by meeting their committments, not the time taken so it’s important to improve estimates as you go along.

Tags:   scrumNo Comments.

The Sprint Backlog is separate to the product backlog and contains more detailed requirements that have been broken down into tasks estimated in hours.  The Sprint Backlog allows the team to see where they are and provides a focus on the work remaining.  It’s a team artifact which does not have to be shown to others.  The whole team is responsible for updating it and it is often viewed as a task board.

Tasks should ideally be 4-16 hours of work.  You want to be able to tell in daily meetings if deadlines are likely to slip.  Instead of someone saying they are 50% through a 3 day task, it’s more accurate if they can say a task is fully complete or not.  The team either signs up for tasks or assigns the tasks as a group, taking into account the task priority and the makeup of the team.

Requirement     Task   Owner   Status       Work left (hours)

R1049               T028    JM        Open          12        6          8

Each day the hours remaining is updated so everyone can see how the Sprint is progressing.  This is then used to update the Sprint burndown chart each day.

Tags:   scrumNo Comments.

You need a Product Vision and a Product Backlog to drive a project.  The Product Backlog is a high level list of prioritized requirements with a rough size and complexity estimate for each of the requirements.  The Product Owner is responsible for maintaining the list, but can get as much feedback as they like from customers or team members.  Priority is set by the Product Owner, size/complexity is set by the team.  The Product Owner uses the backlog to manage the release plan and it’s used by the team as input for the Sprint Planning Meeting.

The priority is set by the Product Owner and should take into account the risks or advantages of leaving the requirement to later.  Usually high risk items will be addressed first.  It’s important to know what decisions you can defer and what ones should be done now.  A factor in deciding this is how difficult it would be to change a decision later.  Good design should keep your options open so you can respond quickly to changes rather than predicting the future.

Each requirement or user story needs to be defined well enough that a complexity estimate can be put on it.  The Product Backlog items are business requirements only, not the tasks required to achieve them.  The items at the top of the list tend to get more defined as time goes on.  It must be updated/groomed regularly.  The Product Owner will often request an Estimation Meeting with the team so that items can be discussed, updated and broken down into small enough stories that can be estimated by the team.  Items will be further defined at the planning meeting to identify tasks necessary to complete them.

Tags:   scrumNo Comments.

At the start of a project, it’s the responsibility of the Product Owner to work with a group of relevant people to create the Product Vision which outlines the broad goal for the project, and tentative release dates.  The Product Vision is required to ensure that everyone involved understands why the project is happening and what the desired outcome is.

The Product Vision is used as a foundation for the product.  It’s short – capable of passing the Elevator Test (describing a project to someone within 2 minutes as they travel in an elevator).  It describes the critical attributes of the product, who will use or buy it, which customer needs it addresses, the target timeframe and budget.  It also gives a comparison to existing products and states the key selling points, but only describes critical information.

The Vision needs to be broad and stable so that it will still be valid as individual requirements change during development, but give a clear goal and focus.  This allows people to take a step back at any point and use the Product Vision as a guide to verify that the project has not gone off track by either developing something that doesn’t match the Product Vision, or incorrectly prioritising requirements.

Tags:   scrumNo Comments.

In Scrum, a project is developed in a number of time-boxed iterations.  Each of these iterations is known as a Sprint.  A Sprint is usually 1-4 weeks long.  The team develops a number of requirements during the sprint, and at the end of each sprint the team is expected to deliver and demonstrate working software that is potentially shippable.  Any requirement that is not fully completed is not counted.  This makes it very clear when targets aren’t being achieved.

Sprint Length:
At the start of the Sprint, the team takes a set of requirements from the top of a prioritised list of requirements called the Product Backlog that’s maintained by the Product Owner.  In the Sprint Planning Meeting they decide how many of these requirements can be accomplished during the Sprint.  The length of a Sprint is determined by how confident a team is and how much uncertainty, newness or risk is involved.  If any of these are high, the sprints should be shorter.  However the length of sprints shouldn’t change too often to allow the team to improve estimates, so choose carefully.

Changing Scope:
In a Sprint, scope is the only thing that can be compromised.  Quality can’t be skimped on.  This is very important to avoid building software that is difficult and time-consuming to maintain.   If the team has over-committed they can consult the Product Owner and drop some lower priority items in order to fully complete the top priority tasks.  Likewise, if the team has under-committed, they can select more items from the backlog in consultation with the Product Owner.

Abnormal Termination:
This doesn’t happen often, but a Sprint can be abnormally terminated if the team feels they can’t meet the Sprint goals or the Product Owner finds external circumstances that cancel out the Sprint goals.  When this occurs a Sprint Review should immediately be held to review the reasons for terminating the Sprint.  Then the team should continue on to a new Sprint Planning Meeting.

Sprint Artifacts:
There are a number of artifacts that should be generated by the end of a Sprint.  They can be used to help improve estimates for future Sprints.

Sprint Burndown Chart – this is updated daily and shows the velocity for the Sprint.

List of impediments encountered – this is kept by the Scrum Master, logging impediments encountered and the steps taken to resolve them.

Relevant quality metrics – this includes things like unit test and code coverage reports.

Sprint Report:
It states the start/end date of the sprint, the team members available for the sprint, the number of working days planned for, versus the ones actually worked (noting sick days etc) and the story points planned versus the ones earned.  Each backlog item that was in the sprint is listed, and an outcome of complete or incomplete.  Finally, it logs the review action items for that sprint.

These artifacts – especially the Sprint Burndown Chart should be highly visible to the whole team.  A scrum team meets daily and at the end of that meeting the burndown chart should be updated so that everyone is  clear about how much progress has been made, and more importantly – what’s still left to do.  This allows the team to judge whether they can meet their committments for the Sprint and raise any issues that may prevent them from doing so.  The artifacts should show estimates improving and a sustainable velocity reached as a scrum team evolves.

Tags:   scrumNo Comments.

The ScrumMaster is the member of the team that’s responsible for guiding the team and ensuring that the spirit of scrum is being followed.  They act as a buffer between the team and external influences. They do any administrative work, run the meetings and help remove any impediments that are blocking the team from delivering their sprint goals.  It’s hard to define the role as it can grow depending on the circumstances.

The scrum master is a non-traditional management role.  As the team is self-organizing, the scrum master is not the leader of the team.  But the scrum master coaches the group and helps them to become a team, acting as a role model and encouraging change.  A good scrum master emodies the qualities of servant leadership – focusing on the needs of the team rather than their own.  Eventually a scrum master may coach a team to the point where their role is effectively obsolete.

The Scrum master is responsible for maintaining quality in a number of ways.  They prevent the team from building the kind of bad quality legacy code that lurks in many companies.  Code that is brittle and awkward – very easy to break, but doesn’t have a good test harness to highlight problems and identify what’s been broken.  There’s usually a shortage of developers that can actually work on the code.  The poor legacy code is what handicaps the velocity of a team in this situation.  This kind of code is the result of repeated development cycles where quality hasn’t been prioritised highly enough.  A vicious cycle occurs where quality controls are cut back to increase velocity and each subsequent release has a slightly lower velocity as the code base deteriorates requiring further skimping on quality.

The scrum master applies controls to prevent this happening.  The team is not allowed to demonstrate any task or story that has not been fully completed in time for the Sprint review.  These items must be carried on to the next Sprint if still relevant.  When there’s a problem with meeting a deadline, the scrum master makes sure that quality isn’t compromised in order to increase the team’s velocity and make up time.  Increasing the hours worked can’t happen often as working longer hours results in reduced quality.   Teams need to maintain a sustainable pace to perform well so the only aspect that should be altered is the scope of what has to be done.  Changing requirements in scrum doesn’t carry the heavy penalties it would when using waterfall, so the answer is to revisit the requirements and make sure they’re still valid and that the most important ones are completed first. The scrum master works with the product owner to reprioritise what must be done.

The scrum master is a difficult role to do well and ultimately has responsibility for how the scrum team will perform.  For this reason, it’s an important role to fill with someone who won’t lead the group astray.

Tags:   scrumNo Comments.

The Product Owner is the member of the team that represents the customer or project stakeholders and has a number of responsibilities.

Product Vision – the Product Owner should write the Product Vision to describe the goals of the project so that everyone is clear on what the team is aiming to achieve.

Product Backlog – the product owner maintains the prioritised list of requirements or user stories.  They’re responsible only for keeping it up to date and can get help and input from anyone they like.  It’s important that the backlog is regularly updated so that changing requirements and priorities can be taken into account for each sprint.  This is how the Product Owner steers the team towards the desired goal.

Release schedule – this is owned by the Product Owner who uses the artifacts generated during each sprint to estimate and keep track of whether a project will meet deadlines.  It’s the Product Owner that monitors for problems with meeting a deadline.  As a project progresses, the amount of business value delivered in each iteration tends to decrease.  The Product Owner watches for the point when the value to be delivered is no longer worth the development effort to be expended.

Finally, it’s very important that the Product Owner be available to answer any questions from the rest of the team and to provide feedback both in daily meetings and reviews.  The Product Owner also helps set acceptance criteria for user stories.  It’s a vital role within the scrum team.

Tags:   scrumNo Comments.