Posts

User Stories – How to write good stories?

User Stories

Recently came across a 20 page long requirements document and didn’t know where to start and what to remember, specially for somebody like me who has a memory of a goldfish. I stopped using those time consuming, long and boring requirements document way back in 2007 and started use cases and then moved to user stories. They are easy to write and understand and best thing about them is “collaboration“. I personally love those user story writing workshops with loads of index cards, post-its, marker and DONUTS. So how do you write user stories?

User Stories:

According to Mike Cohn User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Title: One line describing the story

Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance Criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
Scenario 2: …

Here is an example from my recent project at Toyota motors.

Sales Performance ReportUser stories

Narrative:
As a [Sales Analyst]
I want [to see parts sales figures for the current month(mtd)]
So that [I can track sales progress against monthly target]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: BI User login
Given [I am logging in as a BI user]
And [some more context]…
When  [the log in successful]
Then  [I will be taken to sales performance report]
And [I will be able to select month and date or defaults to current month and date]

Hope this helps! Good luck with user story writing and don’t forget to buy donuts (skinny ones for me please!).

, , , ,

What is technical debt?

Our team is about to go live in few days and we are still discovering loads new issues. Of course frustration is mounting and its getting harder and harder to explain the extra work team needs to do. When someone in the team suggested to go back to the drawing board, my heart sank into my stomach. I did some research, and came across Martin Fowler’s articles man-carrying-donkeyabout technical debt and it felt like deja vu moment. So what exactly a technical debt( or code/design debt) is? The picture on the left describe it very well.

It is:

  1. An unsustainable design that is chosen as a shortcut to make a release. Where the release offers sufficient value to the customer, a PO might accept (or even request) such a shortcut.
  2. Messy or badly written code

The former is a deliberate and prudent decision. The team is aware what is happening and that the design shortcut has to be rectified in the following spring.

The latter is either reckless or inadvertent. The programmers might not be mature enough to know that they are injuring debt (that their code design is not sustainable); we call this inadvertent debt. Or the programmer might not care; then we call this reckless.

Finally, we might only know that we incurred debt after the fact, i.e. we only find out later that our design is not sustainable.

In general, technical debt is a metaphor to explain to POs or stakeholders that there are issues in the code base that have to be addressed in order to keep the code sustainable. Unpaid technical debt means that whenever we want to make changes to the code, we have a bigger effort, because we have to work around the debt. So using the metaphor, we are paying interest and like with interest on a credit card, this can grow to the extent that all our time is used to pay down interest.

Like with a credit card, if we keep using it without paying back the debt, we lose at some point the ability to incur new debt, i.e. we lose an option to cope with exceptional circumstances. It is therefore sensible that technical debt is paid down as quickly as possible.

What do we do in a situation where such debt has become crippling? In an environment I worked in as a coach with an aggressive delivery deadline, the defects were so massive that team was almost unable to make any progress on customer value. There was no way all defects could be cleaned while adding features at the same time. So there was a threat of having a poor quality product by the time the project went live, something the PO and the stakeholders were unlikely to allow. The project was in risk of failure.
To address the defects, it was agreed that the team would do short sprints(1-2 days) until the debt was under control.

A backlog of defects was created and shared with the PO and Stakeholders. Every morning the progress from the previous day was reviewed and the process itself was examined in a small retrospective. Then the work for the day was prioritised and the team would make the agreed improvements.

So every day, a full scrum cycle was carried out. This brought the development back under control and the quality back where it needed to be. In the end, the project was allowed to go live.

In another case with delivery pressures, under inspection it become clear that for a release, it wasn’t necessary to actually deliver a fully functioning version. What the PO was really after was being able to show how the final system would look and behave like to users. The team was able to ignore some inter-system dependencies in the planned release and the PO agree that team would be given time in the following release to resolve these issues.

In this scenario, the debt was treated like features. In cases where work has to be done that is only indirectly related to value the customer can perceive, technical debt can be treated like a story with its own card and estimate. Where debt is an ongoing issue, the team can ask to have a fixed amount of time in each sprint to address debt. This is not uncommon in Scrum teams working on legacy systems.
Learning:

• Technical debt can come in various forms, deliberate or unknowingly. We can be aware we have debt or we might not know.

• Technical debt taxes progress and if not resolved can cripple a project.

• We should pay down debt as quickly as possible.

• Debt can handled like stories and be subject to prioritisation.

• It is good to discuss debt – where we’re aware of it – with POs and Stakeholders so they help prioritise how we pay it down and are aware of its existence.

I suggest team should plan code refactoring as part of sprint backlog. This will keep them on top of technical debts and make code design clean and sustainable.

Happy coding and stay agile.

AgileKrish

Reference:

  1. http://c2.com/cgi/wiki?TechnicalDebt
  2. http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
  3. http://www.martinfowler.com/bliki/TechnicalDebt.html
, ,

New to Agile?

In short, agile and lean are general concepts, the former basing on Agile Manifesto and the latter on Toyota Production System. Then we have Scrum or XP, built over agile, and Kanban, built over lean, which are specific methods teams can implement, like Prince2.

Personally, I don’t treat agile and lean movements in a very orthodox way — they base on the same principles. So, to some point, they’re overlapping. Also, you will find teams mixing methods from both houses, Scrumban (a combination of Scrum and Kanban) being probably the most common.

If you wanted to position agile/lean methods somehow I’d say that:

  • Scrum is the closest to the old-school project management methods, although it doesn’t really deal with formal side of project management.
  • XP focuses on engineering practices and is generally programmer-centered.
  • Kanban is often dubbed change management framework as it doesn’t change the way team works on the day 1 and lets the process evolve over time.
  • As all three focuses on different things, it isn’t uncommon to see them, or their parts, used jointly.

If you want to learn more I’d start with such set of materials:

  • Introduction to Scrum on Mike Cohn’s site. If you want more on Scrum Mike Cohn’s site is a good place to find also more advanced stuff on Scrum.
  • Once you know what Scrum is I’d strongly recommend Henrik Kniberg’s and Mattias Skarin’s minibook Kanban and Scrum – Making most of both which is great in terms of describing Kanban but has a lot of referrals to Scrum.
  • For more advanced stuff on Kanban I’d recommend Limited WIP Society articles (topic for my next blog).
  • Good kick start on XP can be found on Ron Jeffries’ site.

In terms of books as a kick start, I’d recommend:

  • Mike Cohn’s Succeeding with Agile for Scrum
  • Kent Beck’s Extreme Programming Explained for XP
  • David Anderson’s Kanban for Kanban

If it is too much of a hassle to read these books and digest then contact us and we may be able to help you.