Requirements to Design

• Before defining a solution (our design) we must first understand the problem we're trying to solve (our requirements)
• What does good look like?
• Define outcome/endstate first
• Then come up with a solution
• Avoid creating solutions to problems that don't exist
• Avoid following processes and practices without a logical basis

Requirements to Design: A Series of Abstractions

• What is the problem we're solving?
• How will we solve it?
• Different people in the team will work at different levels of abstraction
• One person's design is another person's requirements
• Power of teamwork - split responsibility from those who define problems to those who solve them

Software Developers vs. Software Engineers

What's the difference?

The Engineering in Software Engineering

• Problem-solving; thoughtful planning and designing; seeing things through from end to end;
• Defining the problems to be solved, not just finding solutions
• Dealing with the unknown, deal with ambiguity
• Learn to deal with unknowns gracefully as they arise
• Domains are often highly specific, nuanced and complex
• When we spend time with a problem, the problem space grows around us
• Transformation of the unknown into the known

Requirements Engineering

• Process of understanding the problem to be solved
• Iterative process
• Team process
• Hardest for people new to the team / junior developers
• As people become more experienced, they can use their context to aid their understanding
• Research, asking questions and clarifying unknown areas is essential

Assumptions

• We make assumptions all the time, implicitly
• When understanding software requirements, we have to make assumptions in order to understand efficiently
• Three types of assumptions
  • Reasonable assumptions that don't cause problems/breakages
  • Reasonable assumptions that do cause breakages
  • Unreasonable assumptions 

Assumptions, interpretations and communication flaws

Ticket Estimations

• An agile meeting (can be combined with grooming)
• Completed once per sprint (to estimate tickets for the upcoming sprint)
• Each ticket to be completed is allocated a number of story points
• Allocating story points is a democratic team process (vote and discuss)
• Story points are not a measure of time - different tasks will take different amounts of time by different team members; time isn't an accurate measurement here
• Instead, we measure relative effort

Ticket Estimations

• Factors to consider include
  • How much work is there involved? (number of files/packages/lines of code)
  • How complex is the task?
  • How much context is required to understand the problem?
  • How much risk is there to the task?
  • How much business value does this task deliver?
  • Does this task rely on other dependencies (other teams) to complete?

Ticket Estimations

• Fibonacci scale used to allocate numbers
  • 1, 2, 3, 5, 8, 13, 21
• Teams should determine their own standard for ticket estimations, with examples of work
• An example of a standard for ticket estimations
  • 1 - very trivial change (e.g. feature flag cleanup)
  • 2 - minor change (e.g. fixing some broken unit tests)
  • 3 - moderate change (e.g. adding a new suite of tests to a function in an API)
  • 5 - significant change (e.g. hard bug fix, large spike/investigation)
  • 8 - can often be broken into smaller subtasks, or is highly complex
  • 13 - this should be broken down into subtasks
  • 21 - Epic (contains a series of tasks to complete)

Why estimate?

• Team/people needs
  • Allows engineers to contextualise their work
  • Manages expectations
  • Get commitment from the team
• Task needs
  • Forces us to ask questions around a task, discover unknowns and grow the problem space
  • Useful for synchronous estimations to spark these discussions
  • Shifting left and moving discovery earlier in the process
• Organisation/planning needs
  • Allows teams to plan capacity
  • Allows higher management to see team progress and measure reliability
  • Allows for optimisation of throughput