Skip to content

Project management & scrum

Jump to bottom
Christian Echevarria edited this page Jun 10, 2019 · 8 revisions

An Overview of Scrum :)

Scrum cycle visualization

A scrum cycle visualized

What is "Scrum":

  • Scrum is a framework that is used by teams in high agile environments that need to adapt to change quikcly, effectively, and in the most efficient way possible.

  • It was built off of Empiricism:

    • Which means that the only knowledge known is that of past experiences.

  • Scrumming uses a process of inspecting, adapting/changing, and transparency for updates and feedback from all team members and people involved.

  • Fundamentally, it takes a really big project or product idea, breaks it down into several increments via smaller tasks or items (by defining certain feature sets or enhancements), and combines an iterative feedback loop for each increment added to test: functionality, value add, and maintaining the quality build out of a product; all under a pre-determined time-box.

    • Timebox: a set of schedules to be able to define and build out incremental items (features or enhancements) through a series of sprints (30 min, 2 days, 1 week, 2 weeks) depending on the complexity of the project.

Scrum empiricism process

Scrum empiricism process

The Scrum Team:

The Scrum Team in any scrum process is divided up into 3 different categories:

  1. Product Owner: usually hired by a client or business, the source of knowledge for the product who defines and communicates the product vision with the rest of the team, and ensures the backlog accurately represents the product vision at hand
  • Product Backlog: the list of items necessary for the creation and definition of the product
  1. Scrum Master: ensures that all members are sticking to their tasks, and is there to help remove any blockers or impediments for the dev team, while maintaining strict transparency and communication with the product owner.
  2. Dev Team: the developers who do the work and execution of the product by building out the features and enhancements defined by the product owner. Also architect, code, and test all items placed on the product log.

A few notes about the Scrum Team:

"The Scrum Team leads and manages themselves"

  • They are self-organizing: Team members can go in and out of roles at different times throughout the scrum time-box. No one team member has authority over the other, and each hold equal authority to each other in doing the best of their job at the time available dependent on their strengths and individual abilities.
  • Need to find tightly focused products to work on initially rather than broad ones.

Defining Sprints:

  • Sprint Questions:

    • What will we deliver?
    • How will we deliver it?
    • Decide on a time-box for the sprints depending on complexity of product, not amount of features.

  • Sprint Goal:

  • Crafted from a bottom up (from cohesive items up to a goal) or a top down (crafted from the vision down to the items).

    • Both also work well together.

  • Sprint Backlog:

  • Defines the tasks
  • Defines the time-box of each task
  • Deliberates the tasks to individuals

  • Scrum Reviews:

    • Held at the end of each sprint session
    • Show more than just demos, show a functional product, pre-set meeting with an agenda

  • Some Sprint Notes:

  • Predictability of a sprint is the goal, not velocity

    • Velocity: the amount of items completed in a given period of time

  • Agile helps deliver to market sooner, which is not the same as velocity

    • Delivering value as fast possible by working in smaller increments
    • Allows for a tighter feedback loop that may simplify the project

  • Add Business Value: have a shippable product due a few sprints before finalized date of product release, but have added feature sets that add 'less' value to the product at the final 2 sprints.

    • i.e. make it look pretty at the end.

Fundamentals of an Ideal Product Backlog:

  • Product Backlog:

    • An ordered list of everything that might be needed in the product.
    • The single source of requirements for any changes to be made to the product.

  • Product Vision: high level strategy of the goals for your product.

  • Product Backlog: the tactical plan to achieve that strategy.

  • Prioritization Strategy:

  1. Technical Necessity: how necessary this feature or item is to be completed for other parts of the project.
  2. Risk: amount of unknown risk associated with each item.
  • The higher the risk, the higher the priority: Higher risk items will require more time to tackle, allowing you more time to solve any blocks along the way without leaving it to the end of the sprint.
  1. Business Value: expected yield of value from overall product Note: Business value becomes a higher priority as you get closer to the end of the sprint, as technical necessity items should have already been built out, and it becomes too risky to work on riskier items near the end of the sprint.
  • Structuring the Backlog:
  1. Opening Game: setting up the environment and all the tools necessary for completing the product.
  2. Middle Game: beginning work and execution phase.
  3. End Game: getting ready to deploy and maintenance related items.

  • Backlog Refinement: 1 hour a week meeting to discuss what is happening with current sprint, as well as using this info in relation to the upcoming sprint as well.

  • Backlog Visualizations:

    • Burning Chart: a chart that visualizes shows the amount of items left to knock out on a product.

  • Notes on Product Backlog:

    • Only give full detail and effort to what is needed at the next present moment; everything else later down the line can be viewed with a brief summary/overview/description.
    • Add improvements to internal team processes as an event to the sprint backlog items as it requires some time needed in place of executing.
    • Plan for a Spike:

  • Spike: times when research needs to be done to further delve into the complexity of an item or answer any supplemental questions which may come about

Clone this wiki locally