While working on the FedEx 2-day shipment story Martin discovers some very crufty code in the Foobar class. He doesn’t need to work in the class to complete the story, nor can he see it causing any bugs right now. He doesn’t want to ignore the issue so he grabs an index card and writes “Foobar class is very crufty and it will slow us down later”.

Later in the day the following conversation occurs:

Martin: “We need to rework the underpinnings of the Foobar class so that we can work faster.”
Product Owner Sue: “Martin, why is that important? Help me see that.”
Martin: “It’s slowing us down. Every time we work in Foobar we spend an extra 20 minutes just trying to understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect.”
Jane: “Can I trust you? Will this be the last time I ever hear about the Foobar class? Where should I put this is in the Backlog?”
…
Read More…

Be Sociable, Share!

• 

Image Credit: robinsonma http://www.sxc.hu/photo/917101

The team has just completed Sprint Planning, committing to four stories:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
  • A review has text and isn’t empty
  • A review has an author name
  • A review has a title
  • At most a review is 2500 characters long

• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
  • Rating from 0 to 5
  • No ½ stars
  • Rating appears at the top of the review

Read More…

Be Sociable, Share!

• 

The recent Backlog Refinement session helped split the upcoming User Stories.

The team was able to get from a very large Story: “As a first time book buyer I want to read a trustworthy review before I buy a book” to:

• As a first time book buyer I would like to read a review so I can see if a book is worth reading.
• As a first time book buyer I would like to see a star rating associated with a review so I can quickly assess if the book is even worth thinking about.
• As a first time book buyer I would like to see reviews by staff members marked separately so that I know whom to trust.
• As a first time book buyer I would like to see reviews by friends highlighted so that I know whom to trust.
• As a staff member I would like to write a book review so that I can help customers choose great books.
• As a staff member I would like to rate a book I’ve reviewed so I can give customers a quick guide.

We’re in better shape than we have been with previous Sprint Planning meetings but the team lacks concrete acceptance criteria.

Analysis

During the first half of a Planning meeting the team is trying to determine its goal for the Sprint. Specifically, it’s trying to answer the question, “What stories can we commit to?”  To have a realistic commitment the team needs small Stories and a clear understanding of what they will look like when they’re done.

Story

Brad reads the first Story aloud, “As a first time book buyer I would like to read a review so I can see if a book is worth reading.” He sees an entire new web page, separate styling and a whole lot of infrastructure to support it. Doug, on the other hand, sees a small addition to each book page. He says that no new style sheets need to be developed. After a few more minutes of debate Product Owner Sue intervenes by saying that reviews will just live on the main page for now. In addition, each review must be under a thousand words and in plain text only. Read More…

Be Sociable, Share!

• 

Picking up from: Learning How to Estimate

The team are still in the Backlog Grooming/Refinement session. They’ve estimated a heap of stories and spotted several that need better Acceptance Criteria. However, there are several stories that Product Owner Sue would like to have worked on which are too large to commit to in a single Sprint. While they could estimate the Stories as they are this seems like a waste of time. They’re better off getting out the scalpel and splitting the stories into smaller parts.

First a quick reminder from – Why Split User Stories:

Read More…

Be Sociable, Share!

• 

Product Owner Sue has learned from her past mistakes (See Not Ready for Planning) and she now holds Backlog Grooming/Refinement Sessions whenever she has enough Stories to be worth Estimating (typically every 2-3 Sprints). During these meetings team members estimate New Stories, split Large Stories and develop Acceptance Criteria.

With 10 new Stories and couple of “Epics” that need to be split, Sue has scheduled a Grooming session for the middle of the Sprint. She has invited all the team members to attend; Kirby (see New People on the Team) comes but is grumbling, “I don’t see the point in this. Its just going to waste precious coding time. Why can’t this just happen in Sprint Planning?” (Editor – Kirby hasn’t quite found his rhythm yet). Sue reminds the team tht the meeting exists so the team can ensure that Product Backlog is well prepared for the next Sprint Planning meeting. In addition, it helps her understand how much of the backlog they can realistically complete before the next release in three month’s time (Editor – yes they have infrequent releases).

She asks that they start estimating her first new story:

“As a frequent book buyer I want the store to remember me so I can add books to my shopping cart without having to login”.

Team members start asking questions requiring clarification:

• Is it OK to leave a cookie behind? Sue -Yes, although it will need to comply with our privacy policy.
• Ian asks, “Are there any other technologies to consider?”
• Does this include being able to see the book in the shopping cart? Sue – No
• What if we don’t have accounts implemented when we start this story? Sue – Then just use a fake/sample account for now

When the questions peter out Team Members begin flipping through their Planning Poker™ cards (I will have some for my readers soon), looking for the right numbers. Kirby just looks around in confusion. Nobody had checked to see if he understood the estimation process. There was a pause and Scrum Master John asked, “What do you know about our estimation process?” The reply was, “Nothing.” John asked if he understood the flaws of traditional estimation – Kirby was sure he had this one down cold, “Yeah, you need to double the figures and then add a fudge factor, but never tell the developers otherwise their work will expand to fit the time available.” There was some nervous laughter, as Kirby has had trouble fitting into the team in the past (see New People on the Team). Read More…

Be Sociable, Share!

• 

Cascade’s team is struggling, three sprints running they’ve been unable to build a potentially shippable product. The developer’s complain there isn’t enough time in a two week sprint to get their work done. They want three week sprints. The testers complain that the only get something to test in the last three days of sprint and even then its usually too buggy to work with. Cascade calls her old friend John who seems to be having more success with Scrum.

John does some digging and finds the following data about (expressed in Story Points). The team had committed to 41 points of Stories sized: 5, 8, 13, 5, 8, 2

NB The in several cases a single story is both in (Analysis and Development) or (Development and Test) at the same time.

Read More…

Be Sociable, Share!

• 

After six months ScrumMaster John has finally found someone to fill the role of Senior Software Developer on the team. The goal is to find someone who can round out the team and play many roles (see: Bottlenecks). After many interviews they’ve settled on Kirby[1] who has over 20 years experience developing software, both server side and GUI. He is a self proclaimed expert in most of the technologies the team uses and that’s where the problems start. In addition the team members assume that he is being very well paid, perhaps better than any of the rest of them.

Attempting to learn the basics of the code base in his first few Sprints, Kirby takes on GUI, Middle tier, Server and Testing Tasks. He asks his teammates for code reviews and the code is pretty good, however it becomes clear that he can be touchy on some subjects and isn’t eager to receive negative feedback. On the subject of feedback he says: “I’m a Senior Developer, I don’t need to learn from you, it should be the other way round”. At first the team just try to accommodate his needs, but after five to six weeks tensions begin to rise. Ian (the Middle Tier guy) feels threatened, he sees Kirby trying to occupy the niche he has occupied on the team. To compensate Ian spends more time doing server side work, which in turn causes Doug some concern. Even Tonia feels a little bit threatened as Kirby starts doing some automation work. Read More…

Be Sociable, Share!

• 

The Team are struggling to payoff the Technical Debt (or mess) that they’ve spent the last six months accumulating. They’ve started to institutionalize writing Unit Tests (by adding it to “Done”) and they’re using Sonar to help track Code Coverage, PMD warnings et al. (Ed: Don’t take Sonar or any other measure as more than a first order view of the code, it hints where you need to look no more).

Story

During the Standup Ian reports that he is starting his third day of refactoring[1], a monster class called BuyABook. ScrumMaster John’s antenna go up immediately, after all the team had split all tasks in one day or less. After standup he stops to have a quick chat with Ian to find out what is up. Ian explains that this class depends on many other classes and as a result it very difficult to test. He continues that he’s been reading the Feather’s book: “Working Effectively with Legacy Code” but it’s a struggle to put the ideas into practice. When he’s finished John talks to Doug and Martin finding that they’re having similar problems.

John puts on his thinking cap, he knows the team needs practice and knows that they need a safe place to do it before they use the ideas in the main stream code. After a few minutes Goggling he stumbles on the idea of coding dojo’s and based on the experience of others: TDD Randori Session, TDD Randori Workshop and My First Coding Dojo. The idea behind a Coding Dojo is taken from the world of Martial Arts. It is just a safe place to practice. In this case John imagines the team would like to be able to practice the ideas that Feather’s proposed either on artificial problem or on a small problem in their own code base. He sees them getting together in a meeting room with a projector and solving a small problem as a team. Read More…

Be Sociable, Share!

• 

Scrum Team digging a hole

The first law of holes is “When you’re in one stop digging”. In the last sprint the team discovered that they’re in a hole – in this case they had dug themselves into technical debt.

We join the team this week in their Sprint Planning session, they start by rechecking their Retrospective action items:

• Respect the “Definition of Done” – write Unit Tests (their complete “Definition of Done): Checked In, Peer Reviewed, Unit Tested, Manually Tested)
• Temporarily add Unit Test column to their story board
• Install Sonar (a platform to help visualize Code Quality) to help improve awareness of Code Quality and Technical Debt
• Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues (Ed note: From experience this seems a bit low for team that have accumulated a fair amount of technical debt, but the team will have to learn on their own)

They start by discounting their historical velocity (currently at ~20 Story points) by 20% to account for paying down the Technical Debt (16 Story Points). Then they recheck the “Definition of Done” for each story they’re about to commit to. At this stage Product Owner Sue pipes up to protest that all this focus on technical debt doesn’t help her get features out the door. She’s concerned the CEO will banging on her door soon. Doug explains that if the team doesn’t start to tackle the technical debt now the delivery of new features will slow down even more, while the bug count rises. He explains that the next 3-4 sprints will be rough the situation needs to stabilised (Ed: He’s optimistic) . ScrumMaster John reminds Sue that she is responsible for the product that the team delivers. In turn the team is responsible for deciding how much they can deliver and for ensuring its quality. Sue raises the flag of surrender but says she is really concerned and wants to revisit this two sprints from now. Read More…

Be Sociable, Share!

• 

Cross Skilling is starting to happen and already there are fewer bottlenecks. John is starting to have more time to step back from the day to day and look at the big picture. He’s heard that most Scrum teams become more productive over time and he wonders how is team is doing. He pulls up the CFD for the current release:

and immediately notices that the rate at which stories are being selected has slowed down in the past few sprints. Historically the team has a trailing average of 30 story points a sprint. In the past few sprints they’ve only achieved 25 and 22. Is this drop meaningful? Is it related to the team’s cross skilling efforts? John decides to ask the team what is going on. He writes a short note, describing the problem he’s seen (without his own suspicions) and asks the team to reflect on the discovery. After Daily Scrum John invites the team members to talk about the problems they see:

• Cross Skilling has slowed the team to a small extent
• Interruptions are down, so if anything the team should be more productive
• Unit Tests aren’t getting written for very often
• Ian and Doug report that they’ve spent a fair amount of time in the past few sprints implementing a new story only to find it broke an existing story.
• Its also noted that there are several places in the code that have become rather hairy and are difficult to change safely.

Read More…

Be Sociable, Share!

•