Trillium Insights

Thoughts and Insights from Trillium's Practice Leaders

What’s the difference between a user story and a task?

What’s the difference between a user story and a task?

Well that’s an easy question, I thought. I began to think and realized it wasn’t actually such an easy difference after all. I’d been using the two terms, "user story' and “task” for years, and they seemed pretty distinct in my head. User stories were on the product backlog and tasks were identified during sprint planning and became part of the sprint backlog. That was fine but wasn’t very helpful—it was like saying “salt is what goes in a salt shaker and pepper is what goes in a pepper grinder.” Sure, stories go on the product backlog and tasks go on a sprint backlog. But what is the essential difference between the two? Then I realized I did know what the difference was. A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.

Let’s see if that works. A user story is typically functionality that will be visible to end users. Developing it will usually involve a programmer and tester, perhaps a user interface designer or analyst, perhaps a database designer, or others. It would be very rare for a user story to be fully developed by a single person. (And when that did happen, the person would be filling multiple of those roles.) A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person. You could argue that some of them are or should be done via pairing, but I think that’s just a nuance to my distinction between user story and task. Pairing is really two brains sharing a single pair of hands while doing one type of work. That’s still different from the multiple types of work that occur on a typical story.

I have, however, used a couple of terms like saying tasks are typically done by one person. Here’s why I qualified my statement: Some tasks are meetings—for example, have a design review between three team members—and I will still consider that a task rather than a user story. So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.

How You Gather Requirements Sends a Message!

How You Gather Requirements Sends a Message!

You are the customer and I am the consultant working with you to develop some software changes for your packaged software. As the consultant I can take two approaches for gathering requirements:

Option #1: “What would you like?” An open-ended question that will generate a lot of feedback from you the customer. Yet it communicates several underlying messages:

  1.    You as the customer will get a turn-key, custom solution.
  2.    Software changes require a minimal effort.
  3.    I as the consultant may not have sufficient knowledge of your business – or not enough to lead with a recommendation.
  4.    You as the customer know exactly what you want.
  5.    I as the consultant appear to be more customer-focused.

 

Option #2: “Here is the delivered functionality. Please explain why this is not sufficient?” A question that will generate less feedback from you the customer. Yet it communicates several underlying messages:

  1.    You as the customer may not get what you want.
  2.    Software changes should not be required.
  3.    I as the consultant may not have sufficient knowledge of your business – especially if I did not know of the gaps beforehand.
  4.    You as the customer may feel to be put on the defensive and not treated appropriately as the key stakeholder.
  5.    I as the consultant appear to be less customer-focused.

 

Both options are valid approaches for gathering requirements. However, the challenges I see today are due to how project teams apply requirements gathering strategies to their project implementations. Project teams typically confine themselves to only one approach and do not account for the challenges associated with the selected requirements gathering method. Based upon my experience there are three main strategies for gathering business requirements:

  1.    Requirements-Driven Strategy
  2.    Solution-Driven Strategy
  3.    Configuration-Driven Strategy

 

A pure requirements-driven strategy focuses on defining all business requirements independent of organizational and technology constraints. This approach is the most widely used method today. This is also the slowest approach to gathering requirements and will require the most time from business users to articulate requirements. We can anticipate gathering non-value-added business requirements that must be filtered through the requirements section process. With additional gaps business stakeholders will have to spend more during Fit/Gap to make decisions.

 

On the other end of the spectrum, a pure solution-driven strategy focuses on the gap business requirements (requirements that cannot be met with delivered functionality). This approach is highly popular in for rapid deployment implementations. This approach requires the least amount of time from business users; however, business activities must conform to the packaged business software. This could have a significant impact on organizational acceptance and impact because software designs are based upon a market-driven set of requirements and not the specific requirements of an individual customer.

 

The configuration-driven strategy is based upon the premise “The new system needs to do what the existing system does today”. It may be a situation where a customer simply needs a replacement system because the existing system is nearing the end of its license and may become decommissioned software. Starting with what the customer knows helps to expedite requirements gathering. Business user time is minimized because IT can provide insight into the existing business system capabilities and configuration. However, this approach will surface requirements based upon existing system limitations as well as legacy non-value-add business requirements.

 

Each requirements gathering approach has its strengths and challenges. This fact does not invalidate the approaches described. What is required is the right application of these methods to encourage – not force – customers to maximize their system’s investment.