Agile Scrum

Posted on Edited on In

Agile has becomes a famous interactive process for developing software.

Why Agile

Why not Waterfall

In a waterfall, every stage depends on the previous stage.

  • Con: no variation, adaptability, or other error once a waterfall project is set in motion.
  • Pro: clear, productive, good time management, and available progress tracing.

Agile is more flexibility, adaptivity, and error tolerable.

Types

Some agile types include Scrum, Lean, and Extreme Programming (XP). This course talks about scrum.

Scrum

There are several roles, backlogs, and Ceremonies in the scrum.

Points

<10 points per task. Fab number is better.

Velocity comparisons by number of points completed per sprint is a senseless way to compare teams because the meaning of 1 point / 3 points / 5 points / etc. is determined by each team internally. One team’s typical 3 pointer could be much harder than another team’s 5 pointer.

Roles

  • Product Owner: maximize the return the business gets on investments. Including salary, company renting fee, facilities, software, and maintenance.
    • They own the product backlog.
    • orders (prioritizes) the items in the product backlog.
  • Scrum Master: a coach who guides the team to an over-high level of cohesiveness, self-organization, and performance.
    • They set the points.
    • scrum expert and advisor
    • impediment bulldozer
    • facilitator
  • Team Member: how work done. What tech and tool to use. Who does which task.

Artifacts

  • Product: list of deliverables for a product.
  • Sprint: the TODO lists of a sprint.
  • Turndown Chart: A burn chart shows how work remains on a given day. It is a good idea to start daily standup with it so that the development team can get timely real-time feedback about whether they are on track or not.
  • Task Board: Tasks of to do, doing and done.

Ceremonies

  • Sprint Planning Meeting: 2h/week
    • marks the beginning of the sprint.
    • commit to a set of deliverables for the sprint.
    • identifies the tasks that must be completed in order to deliver the agreed upon user stories
  • Daily Scrum: < 10 mins, every week day
    • hold this meeting at the start of their work day
    • inspect and adapt the work the team members are doing
  • Story Time: 1h/week
    • product owner will do: Define and Refine Acceptance Criteria
    • discussing and improving the stories in your product backlog, which contains all the stories for future sprints.
  • Sprint Review: 30-60-120/sprint
    • invite any and all stakeholders.
    • demonstrating the stories that did get done.
    • stakeholders will have feedback and ideas, and the product owner and the team members will gather this feedback.
  • Retrospective: 1-2 h/sprint
    • Only the team.
    • focus on what was learned during the sprint, and how that learning can be applied to make some improvement.