Blog

Reach Us

31 Aug 2010 - 9

Template of task breakdown for a user story

In a few Agile/Scrum training and coaching engagements that I have been involved with, I shared the template of ‘task breakdown for a user story‘ and found that teams find it very useful. This task list also defines ‘done’ criteria for the story. I am sharing the same template with everyone in this forum for your reference.
As a rule of thumb, I recommend scrum teams to define a user story that can be completed in 5 Scrum working days by one or more members. Also, as a rule, the task should be granular enough to be completed in 5 hours max (1 Scrum day). Defining granular tasks enforces discipline among team members to develop and deliver small chunks of functionality everyday to mainline source repository instead of delivering a large chunk of code together which is more error prone.
Here is a list of task breakdown for a user story. Please note, this is a reference list and all tasks listed below might not be applicable to each story.
  • Design for the story – This task is specifically for white boarding or group discussion on how story will be implemented.
  • Implementation of the story – This task could include defining the interface and methods needed to fulfill the story. There can be multiple tasks for this type.
  • Write unit tests (TDD) – I encourage and enforce teams to write code using Test Driven Development (TDD). For any coding story this task is mandatory.
  • Write Acceptance tests – This task is used to write the automated acceptance tests that will help with the story acceptance.
  • Non functional requirements (NFR’s) – For each story, quality attributes like security, performance, usability, testability, maintainability, extensibility and scalability must be considered.
  • Code Review – As a rule, every piece of code delivered to mainline repository should be peer reviewed.
  • Code Re-factor – Beautifying the code by restructuring. This task should be included for each story to avoid a complex mesh of code later.
  • Mock interfaces – At times, development can take a while to produce real implementations of the interface. In such cases, mock interfaces must be provided to help QA engineers with a head start.
  • Exploratory testing -Perform Ad-hoc testing for the story. This could include performance testing, scalability testing, etc.
  • Bug fixes – Depending on the story, appropriate time should be devoted for bug fixes
  • Bug verification – Depending on the story, appropriate time should be devoted for bug verification
  • Demo – Internal demo of the story within the team. I like to add this task as it helps Scrum team members to be on the same page. After the daily standup, if a story is complete members can take few minutes and educate others on the implementation of the story.
  • Update Wiki or document repository with the design and findings of the story
  • End user documentation – This is for updating the reference guide, Install document, etc, if applicable.
There could be other tasks for building on the CI server, Integration testing, etc that might have to be included based on your environment. If you can think of any additional tasks that I am missing from the above list please share the same so I can update the above template.

Scrum team organization - Feature teams

29 Jul 2009 - 3

Scrum team organization – Feature teams or Component teams – Part 2

Component Teams (CT) are specialized teams organized around the architecture of the product under development. Examples of such teams are UI / User experience teams, Database design and modeling teams, team of Architects, Security team, etc.

A typical component based scrum team is more or less similar to a feature team i.e. each CT will have 3 to 4 developers, 2 to 3 testers, a Product Owner & Scrum Master with Documentation and Architect representation as needed.

The top node of the diagram “Theme/Epic”depicts customers value add features (Features that customer value). Think of this as some high level requirement that marketing will use in their presentation to advertise a product. This value add feature might not be small enough to finish in one sprint and gets decomposed in to multiple smaller features i.e. Feature 1, Feature 2, Feature 3, and Feature 4. What this essentially means is, once Feature 1 through 4 are done in its entierty, the top level Theme/Epic is “Done”.

The stories for component based teams are fed by these decomposed features Feature 1, Feature 2, Feature 3, and Feature 4. As the diagram shows, Feature 1 is dependent on Component Teams C1, C2 and C3. Similarly, Feature 2 is dependent on component team C1 and C2, Feature 2 is dependendent on CT C1 and C3 and so on. Component teams in general provide functionality and serve multiple Features. Component teams generally don’t generate products that get shipped to the customer. But they develop functionality that is consumed by feature teams and indirectly helps add value to the features being delivered to customers.

If organizations are structured in a way that specialized teams are spread globally then forming component based teams might make sense. Component based teams are great to keep site affinity, work across different timezones and also to keeping team culture intact. But it also comes at an expense of management overhead.

Few challenges with component teams based on my experience

  1. There is overhead of integrating component team’s delivery with the top level features. In the example above, when C1, C2 and C3 finishes the deliveries for Feature 1 they have to be integrated together in Feature 1.
  2. To ensure all scrums are aligned well to deliver end-to-end customer functionality, it will take lot of upfront planning as well as tracking during the entire sprint.
  3. In my experience, with component based teams it’s very difficult to deliver thin slice of end-to-end functionality at end of each iteration because feature team needs time to harden (stabilize code base + write integration tests) their code with component team code delivery.
  4. Since component team serves multiple features teams, negotiation needs to happen between Feature Team and Component teams to avoid starvation. For Ex. In the diagram above Component Team C1 gets requirements from Feature 1, Feature 2, and Feature 3. In the upcoming iteration let’s say C1 can only serve Feature 1. In this case Feature 2 and Feature 3 teams will have to wait until next iteration before their needed functionality is delivered and will be starved.

Thus, for component teams to succeed open communication channel should be established throughout the organization.

Please share your experiences.