Agile 101

Product Management

At Def Method, we use Agile Methodologies or Scrum when working with client teams. While Agile can feel a bit “buzz-wordy”, we believe in the core tenants of the philosophy - rapid iteration cycles and clear communication across the team makes for great products. Below we’ve outlined some of the key components of Agile that we like to use on projects.

User Stories 101:

What is a User Story?

○     The user story is a short, simple description of a feature told from the perspective of the person who desires the new capability. This is usually a user or customer of the system. It describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

○     A user story expresses one very specific need of a user. It is a self-contained unit of work agreed upon by the developers and stakeholders

○     Typically, user stories take this form:

AS A ____________   (←Person Requiring Action)

I WANT TO _________ (←Requested Action)

SO THAT ___________ (←Business Justification / Benefit)

○     Example:

AS A consumer

I WANT to create a customized shopping list

AND I want to be able to access this when I log into my online shopping account

SO THAT my shopping experience is improved


Why user stories should follow a specific structure:

○     Structured user stories help clarify and clearly communicate the work to be completed to both the engineering team and non-technical team members

○     A good user story can convey a good understanding to programmers about requirements while also conveying a good understanding of acceptance criteria to the product owner


Writing a good ticket:

○     User stories are communicated with the team in a ticket that is created on a project tracking tool of your choice- we typically use Jira, Pivotal Tracker, or Trello

○     Basic ticket writing includes:

  • A good user story
  • Acceptance criteria
  • Informal background information for context
  • Supporting documentation
  • Designs, screenshots and/or wireframes
  • Blockers
  • Sub-tasks
  • Reporter, assigned to, owner, etc.
  • Updated ticket status, priority,labels, story points, epic link and sprint info

Epics 101:


What is an epic?

○     An epic is a group of user stories that have one common objective.

○     Best practice is for an epic to be able to be completed in 1-2 sprints at most

○     An epic should deliver a working piece of functionality or a critical ask that stakeholders can review, interact with and/or provide feedback

The idea is to break work down into shippable pieces, so that large projects can actually get done and you can continue to ship value to your customers on a regular basis

○     Scope can be flexible

  • As a team learns more about an epic through development and customer feedback, user stories will be added and removed as necessary
  • Creating epics around a team’s quarterly goals, roadmap items, planned feature releases or Objectives and Key Results is a great start
  • In general, any scope of work that the team estimates at “weeks” (or longer) to complete, rather than “hours” or“days” should be considered an epic and broken down into smaller stories


When creating and maintaining an epic:

○     The epic purpose / goal should be stated clearly

○     The epic should include an executive summary in the description

  • Management will likely reference epics for status updates rather than stories


Tracking progress on epics:

○     An epic burndown chart shows the actual and estimated amount of work to be done in a sprint or epic. The horizontal x-axis in a burndown chart indicates time, and the vertical y-axis indicates stories or issues

○     By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly. By monitoring a burndown chart, it becomes clear how the team is progressing and where the blockers are

Bug Writing 101:


What is a bug ticket?

○     In software development, a bug is not a creepy crawling thing, but rather a glitch in the system where the program didn’t behave in the way the team intended it to. When members of the product team encounter a bug, they will write a ticket for the bug in the tracker tool. Below, we outline what that process looks like.

How to write a bug ticket:

○     Have an accurate ticket title

  • Example: “File Manager Crashes”

○     Describe the bug in 10-12 words. Quickly and uniquely identify, and explain the problem (not the solution)

  • Example: "Cancelling a File Copy dialog crashes File Manager"

○     Write precise steps to reproduce the bug (it’s important that the developers can get the same bug to show up on their computers so that they know where to fix the code)

  • Write what the expected results were and what the actual results were
  • Provide additional information such as the browser you were on, the type of computer you were on, etc.
  • Provide screenshots when possible

Read Next Article -->