Agile Notes

• 2018/10/28

• Keep tasks as small as possible. Large tasks hide work, make estimates fuzzy, and cause delays. Smaller tasks make it easier to clarify requirements with clients and teammates (divide and conquer to reduce misunderstandings).

• When breaking tasks down, write what “done” means and the purpose. Naming a task with just a noun leads to mismatched expectations.

• Daily standups matter. Cover (1) what you did yesterday, (2) what you are doing today, and (3) issues you found. Leads should listen rather than monopolize the meeting.

• Hold at least one of a morning, noon, or evening sync. Without regular touchpoints nobody knows who is doing what, which invites delays. Sharing work makes it easier to resolve blockers as a team.

• Manage your personal tasks. Summarizing what you will do today and problems from yesterday makes tomorrow’s planning easier.

• Run KPT (Keep/Problem/Try) retros. Weekly at first, then biweekly once the team gets used to it. Monthly is too sparse—you forget what to reflect on; too often and you run out of topics.

• Manage tasks with sticky notes on a task board rather than a spreadsheet. Tools like Redmine or JIRA are fine, but beginners benefit from something you can grasp at a glance.

• “Naive theories” are rules of thumb grounded in experience. Put them into your own words to deepen understanding, and teach them to others to turn them into principles.

• The iceberg model reminds us that visible “events” hide deeper patterns, structures, and mental models. Mental models are shaped by values and biases, so changing habitual events is hard without dialogue at the team or project level.

• Scrum is an agile (iterative) framework. It comprises sprints, sprint planning, daily scrums, sprint reviews, and sprint retrospectives.

• Roles are product owner (ultimate owner), development team, and Scrum master (supports the team in delivering value).

• The product backlog lists requirements, requests, and features. The sprint backlog is the subset selected for the sprint. An increment is the working product.

• Scrum stresses transparency, inspection, and adaptation; it is empirical—you improve by failing early and adjusting.

• Stakeholder collaboration is critical. Share the risks of delay and iterate together.

• Use burn-down charts to visualize remaining work.

• Identify blockers early. If the team cannot resolve them, escalate quickly to the customer.

• Keep MTTR (mean time to recovery) in mind as an operations KPI.

• Developers, testers, and designers should collaborate from the start; waterfall-style handoffs slow you down.

• Scrum emphasizes people and interaction, high-caliber software, customer collaboration, and responding to change.

• Story points measure relative size, not hours. They capture complexity, effort, and risk.

• Planning poker (a.k.a. the wideband Delphi method) has everyone estimate in points, reveal simultaneously, and discuss outliers. Converge by repeating until the spread shrinks.

• Estimate with the people who will actually do the work for better accuracy. Fix release dates if needed, then plan around them (release planning).

• Critical Chain Project Management (CCPM) avoids per-task buffers and manages a shared buffer. It can boost productivity but becomes risky if you burn the buffer too early.

• Parkinson’s law (“work expands to fill the time available”) is why CCPM can help.

• SoE (Systems of Engagement) focus on end users and relationships; SoR (Systems of Record) support business processes.

• A “Scrum of Scrums” is a meeting where Scrum masters from each team sync up.

• Conway’s law: architecture mirrors the organization, and vice versa. Small teams tend to adopt architectures aligned with their specialties; large organizations split roles and the architecture starts to mirror the team boundaries.

• A “daily cocktail party” links communication paths via three meeting layers: team standups, team-lead syncs, and PM/PL syncs.

• The design process typically flows through overall concept, sketches, paper prototypes, wireframes (information design), visual design, then coding (HTML/CSS). Some teams build functionality first, then layer on design.

• Write user stories with WHO, WHAT, and WHY.

• INVEST criteria:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

• Garrett’s five planes for UX design:

  • Surface – visual design
  • Skeleton – information, navigation, and interface design
  • Structure – information architecture and interaction design
  • Scope – content requirements and functional specs
  • Strategy – user needs and product objectives

Design flows from strategy up through visual design.

• A hypothesis canvas is based on Jobs Theory: customers “hire” products to get jobs done. Map the purpose, vision, and solution on the canvas. Similar tools include the business model and lean canvases—create one that fits you.
• MVP (Minimum Viable Product) means the smallest product that still delivers value. Iterate through Build → Measure → Learn. When story mapping your MVP, think in terms of breadth and depth.
• User interviews gather insights about what users seek and the problems they want solved.