What makes a good ‘Story’?

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable


Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

Negotiable

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.

Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation.

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope.

Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive.

Advertisements

Backlog Refining Crib Sheet

Purpose of backlog refining:

  • Prepare stories for planning
  • Provide Product Owner with a rough estimate to aid their planning
  • Breakdown epics into manageable stories
  • Verify stories take us towards our goal and fit with our vision.
  • Identify Spikes

When?

Refining should happen for at least 2 hours each sprint to stay on top of the backlog and ensure that there are sufficient stories estimated to be ready for planning – preferably a number of sprints ahead. (early in a project more time may be needed to get ahead)

Who?

  • Product Owner
  • Scrum Master
  • Entire Development Team

Before you begin

Product Owner should order backlog by his current perceived priority.

Agenda

The Agenda is the backlog, move through the stories one at a time estimating or breaking down epics until the timebox has expired. (or all stories in backlog are estimated)

Timebox

The Scrum Master (or designated facilitator) should ensure that the meeting is time-boxed. Refining is tiring and has taken us away from the current sprint. Keep to the allocated time and schedule another meeting only if it is necessary.

Focus

The Scrum Master must ensure the discussion remains on topic. If a discussion is getting into deep detail on the solution it is likely you are off topic. The goal is to give a rough relative estimate, keep discussions to a high level. If the answer to a question wouldn’t alter your estimate you probably don’t need to ask it.

Estimates

There are a number of techniques for estimating PBIs, some teams use relative story points, some use T-shirts.   The value in the estimates is to the Product Owner and not the team – although there is some indirect benefit.

Story estimates should not be confused with Task estimates which occur at Planning Sessions.   Estimates should be of the relative size compared to other stories (it is not a measure of complexity). Many teams find it useful to identify an initial series of stories to use as your benchmark, or to create a datum to guide estimates.

An proper estimate is the relative size of a story to meet the definition of Done, including any requirements for documentation, testing and delivery – i.e. the package not just the coding.

Note: Estimating is tough! But it is not unique to Scrum, there are dozens of books on estimating software development. Scrum takes a view that estimation by a cross functional team is better than estimation by a single individual.

Story Breakdown

The refining meeting will often identify ‘Epics’ or stories that are too big or complex to estimate or to fit in a single sprint.  A skilled ScrumMaster can help the team breakdown stories into smaller slices that still have business value, it may be necessary to arrange specific story-writing sessions for some of the more tricky stories. There are a number of different techniques that can be used to break down stories.

Note: Story writing is tough! It will take time to get used to story writing and to find a level that suits the team, it is an acquired skill, and there are many techniques. A good Scrum Master may make the process a little easier.

Why Agile?

I feel a little on the defensive recently, I have heard a Product Owner (ex PM) complaining that he could get it done quicker with Waterfall, and I have heard a number of people asking what was wrong with the old way and why Agile?

Short-term memories, fear of change – especially for a very large project manager community – teething troubles with the transition, and a variety of other factors are probably behind it.  But long-story short I was asked if there were any metrics on the comparison between Agile and Waterfall that we could use to ‘reassure’ some of the senior stakeholders.

After a bit of research I found an interesting survey: Dr. Dobb’s Journal 2013 IT Project Success Survey. Posted at www.ambysoft.com/surveys/

173 companies were surveyed: The companies were asked how they characterised a successful project.   Only 8%  considered success to be On Schedule, On Budget AND to Specification.  Most classed success as only one or two of these criteria.

Success criteria 2

Based on the criteria listed above and even knowing that success may be just one of those criteria,  only 49% of Waterfall projects were considered successful compared with almost 2/3rds of Agile projects considered outright successes.

Successful projects

When considering failed projects (projects that were never finished) nearly 18% of Waterfall projects were deemed failures compared to only 6% of Agile projects.

failed projects

Finally Projects that were considered challenging in that they were not deemed successes but were eventually completed.

challenged projects

Ultimately in my opinion “Why agile?” is the wrong question. The questions should be “How can we improve?” I believe that Agile is a philosophy rather than a Methodology.  I’d go so far as to suggest that if an organization has a desire to continually improve and follows through on that, then they are ‘Agile’ regardless of the methodology they use. And a company that follows an Agile framework without a desire to improve is not.

In other words ‘Agile’ is the answer to the question not the question itself. If done right and done with the right intentions Agile can help many organizations improve and improve further. Agile is not a destination.

Impediments

As a Scrum Master there are all sorts of things that get flagged as impediments that you are expected to resolve, some trivial some simply impossible.

My favourite of late was in a planning session, a member of the team said “please take this biscuit away, I have had far too many”  I stepped in seeing an impediment to remove and … ate it. Once again balance restored and my duty done!

But looking back I think the most persistent impediment is recruitment. Most of my teams over the last few years have been composed of a good proportion of contractors and/or growing teams. There always seems to be more work than we have developers.   I have recruited an average of 3 people a year for the last few years, sometimes spikes of recruitment sometimes just the odd replacement. But recruitment is time consuming. For each person hired, 4 or 5 are interviewed, for each person interviewed there can be 5+ CV sifted and considered.

I estimate each new hire consumes close on a full week of effort when you factor in interview time, preparation reading CVs and chasing recruiters, and often of more than one person involved in this process.

The bigger cost may be the impact on the team, a new person is disruptive, they change the dynamic of the team. They are unknown and may or may not live up to expectations.

Retaining staff is hard, the Inland Revenue continues to make life difficult for independent contractors and they are fearful of the implication of long contracts, and a buoyant contractor market means they can move around easily. Recruitment of permanent staff is much harder and a slower process. In the Civil Service because of the austerity measures permanent employees face an assurance of no pay raise or bonuses for the foreseeable future and the offer of below average wages. I still see the occasional good candidate but pickings are slim.

Odd requests

Busy week this week so I have not had opportunity to finish my notes on the Product Owner role, but I’ll come back to that soon.

But I thought I’d do a quick post about some of the odd requests you get as a Scrum Master. A couple of the team have been asking for alternative ways of updating the task board. Post its are not sticking well enough and one or two fall off (post it branded ones) if I use the unbranded ones they all fall off overnight. Index cards and blue tac is a pain.

One of the team suggested magnetic index cards. I did some research and didn’t find anything suitable. But then I found a place where you could have postcard sized fridge magnets designed and printed. They looked just the thing, so I spent my Friday evening designing fridge magnets that resemble index cards and ordering a few packs. The printers will think I’m crazy no doubt. My wife certainly thinks I’m odd – spending my Friday evening making coloured index cards.

I’ll post again when they arrive.

Task PostCard

Explaining the Task-Board

Task Board overview
Task Board overview

The task-board is very personal to each team, some teams use virtual boards from their software tools e.g. Jira or TFS but in my experience most prefer a tactile board.  Moving index cards or post-its or magnets to show status of the story in progress.

My preference is to also have other documents displayed near the Task-board to help remind the team of certain commitments and to aid them in remaining focused.

1. I like to see the sprint Goal, having this displayed by the task-board makes it convenient for one of the team to pose the question – “Does that help us move to the Sprint Goal?” when a team member proposes adding a new task. It keeps focus and an awareness of direction.

2. I also like to display a list of the impediments raised by the team and if possible the status of them. When resolved they are removed, but when visible it is a reminder to the Scrum Master and the team that there is an impediment we should be looking to remove ASAP.

3. The burndown chart is an obvious example of visible data that is useful for the team. It should be updated daily in advance of the stand-up so that it is available to be discussed as part of the stand-up meeting. In addition to the standard 3 questions I feel it is important for the team to be aware of our progress and when appropriate to discuss what action may be necessary to take.

4. Displaying the commitments from the last retrospective becomes a reminder to the team to be looking to improve, not just the explicit commitments but a general desire to get better.

5. The final document I like to keep near the board is the Definition of Done (and usually the definition of ready too).  The definition of done is the team’s agreement to a quality standard. But more than that it is a way of reminding the team that ‘Done’ is more than coding functionality.  It is very common for a developer to say “We’ll be done in an hour”,  to which my response will regularly be “But will you be done?” and point at the definition of done, usually prompting a clarification to “I’ll be ready to deploy” or “I’ll be ready to hand over to <X> for Smoke testing”. It may seem pedantic, but reminding them that done is a collective agreement and not a single person delivery helps the team work together.

All of these documents are displayed openly in the Team room visible to anyone interested, but they are useful only to the team.

Team rooms will often display far more than this, cartoons, story writing tips, Velocity charts, spider diagrams, support rotas, but the 5 documents listed are the ones I find most useful and encourage any team to keep upto date and visible.

Product Owner Role – Overview

I have been asked to give a summary introduction of the responsibilities of the product owner role to a budding Product Owner.  They are due to go on a training course in around six-weeks so this is much more of a high level introduction to the expectations of the role.

Product Owner Overview

I began by outlining some of the core expectation of the role, the delivery expectations and the importance of the role in the process.

But the crucial and generally time consuming aspect of the role is the co-ordination, interaction and management of the stakeholders.

Product Owner Stakeholders

The Product Owner is one of the hardest roles in Scrum, being lobbied by users, the business, the team and others.  Giving time to users to properly understand requirements, understanding the goal and vision of the project/product. Identifying priorities. Being available to the team. Making decisions and all the while knowing you are the single wring-able neck, the one person responsible for the success of the project.

The Product Owner is involved in writing stories, planning releases, setting the product vision, the sprint goals and constantly ensuring that the backlog is up to date and prioritised.

It is not for the feint of heart.