Agile & Scrum Flashcards Preview

Project Management > Agile & Scrum > Flashcards

Flashcards in Agile & Scrum Deck (21):

Illustrate the Agile Sprints

A image thumb

define agile

Agility is an iterative model with the ability to create and respond to change in order to profit in a turbulent business environment — balancing flexibility with stability.

Instead of structured plans and detailed specifications and objectives, agile is unsure about what will be done, how much value be created, in what timeframe.


traditional vs. agile

Traditional planning 

delivering a set scope within a set budget within an estimated amount of time

Agile planning 

greatest value in terms of functionality, as defined by the client, within a fixed time


Core Beliefs of Waterfall

  • Requirements to build the software product properly are known at project start
  • Accurate customer feedback of their want and needs at project start
  • Customer feedback is only needed at the end of the project
  • Project status = completed milestones
  • Separate groups that effectively do analysis, design, code, and test. There is little loss of information in the handoff between these groups.
  • Handoffs can be done effectively by writing down what was done in each step.
  • You can test at the end and get the required quality
  • Management can effectively schedule time


Core Beliefs of Agile

  • unknowns from the start
  • customers unable to give accurate wants at the start; instead proceedingly gaining clarity 
  • get customer feedback as often as possible
  • give developers frequent feedback
  • working code is the most accurate way of seeing the progress of the development effort
  • collaboration minimises delays as well as the loss of information between people
  • testing early and during the development cycle improves the conversation between developers and customers and testers and, thus, improves the quality of the code
  • management sets work expectations, not how that work is done
  • transparency


5 phases of a project

  1. requirements
  2. design 
  3. implementation
  4. verification
  5. maintenance



Some agile guidelines

individuals and interactions over processes and tools

  • value your people and their relationships; part of the value system
  • brainstorm, share understanding, develop shared objectives and collaboration
  • nothing should ever be thrown over a wall in an agile world
  • never let your tools define your process; define process, then choose tools

working code over comprehensive documentation 

  • give them enough to be getting on with
  • problems to solve
  • some wireframes
  • data samples
  • and even make some of it deliberately vague, so a conversation has to occur

customer collaboration over contract negotiation 

  • more than asking customers when you don’t know an answer
  • have them in planning, get them in the room with you
  • having stakeholders interact with engineers and designers can produce real ‘Aha!’ moments — face-to-face
  • collaboration is built on good trust and, if so, the need for formal contract is less

responding to change over following a plan 

  • “I have always found that plans are useless, but planning is indispensable.”


When to be agile


  • requirements are not clearly understood
  • there a prototype is quickly needed
  • project can be broken down into increments, which can be carried out in series of iterations


purpose of prototypes

customer feedback: created to help the customer identify and refine requirements and design features

other reasons may include

  • Display or show the new product (e.g. for investors)
  • Test an idea to see if it really works.
  • Test the design to see if it passes certain requirements.
  • Use it to evaluate where improvements are necessary.


sprints / iterations

one development cycle in an agile project

  • Each iteration is reviewed and critiqued by the project team, which should include stakeholder representatives
  • Insights gained from the critique determine what the next step should be in the project


how is collaboration a foundation in agile

Collaboration encourages a strong relationship built on mutual respect and trust

That respect and trust is what increases productivity, reduces development costs.

Collaboration between

  • business and development teams
  • customer and project
  • supplier and project 



Transparency and agile methods

  • essential for agile methods. 
  • the team’s plan and progress is very public
  • anyone that has an interest can ask and see



Benefits of Agile methods

  • Working software is delivered much more quickly and successive iterations can be delivered frequently, at a consistent pace
  • Closer collaboration between developers and the business
  • Changes to requirements can be incorporated at any point of the process – even late in development
  • Opportunity for continuous improvement for live systems
  • Highly transparent


Limitations of Agile methods


  • Often more difficult to understand than linear methods (initially)
  • Documentation neglected too much may cause issues
  • Bad agile implantation is costly, inefficient, cause culture conflict
  • Not knowing when to stop iterating
  • Potentially difficult to monitor and control


more agile guidlines

  • create personas: summary of all project stakeholders
  • delight the customer, not just satisfy
  • give the customer early and continues software delivery
  • face-to-face meetings
  • build projects around motivated individuals; give them the environment and tools they need, and trust them to get the job done
  • agility promotes sustainable pace; sponsors, developers, and users could continue indefinitely  
  • continuous attention to technical excellence and good design
    • but just enough quality is enough
    • don’t spend days regression testing a feature that you’re not sure of the value of
  • keep it simple; be smart and don’t waste
  • at regular intervals, the team reflects on how to become more effective


What is Scrum and benefit of breaking down project?

An agile approach to develop a product in a team.

  • breaks a project into a number of increments of about two-week duration called sprints or iterations.
    • Within sprints, Scrum breaks individual activities into a series of small steps which are listed in a backlog.
  • Daily progress reportings (working off backlog), called short ‘stand-up’ meetings.
  • Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed.


Core Concepts of Scrum

  • Set iteration lengths (sprints), for example, one week or month.
  • Prioritisation of requirements such as user stories or use cases. 
  • Regular reviews and planning meetings (stand-ups) often limited to 10 min.
  • Two key roles; ScrumMaster, ensuring the process agreed by the team is followed and the Product Owner a key member of the team, often from the client organisation, ensuring that the key goals are prioritised and developed.
  • Scrum covers some of the project management processes. Some agile developers are scaling this and adding governance processes.


Stand-ups in Scrum

  • give people a sense of day-to-day progress
  • contains a formal review of progress every 24 hours
  • ensure that problems can be highlighted and managed
  • important to keep them focused, rhythmic and short
  • Scrum masters should facilitate and keep the rhythm consistent. 

Attendees: team members, product owner, anyone with an interest

  • To support improvement
  • To reinforce focus on the right things
  • To reinforce the sense of team
  • To communicate what is going on


Showcases in Scrum and its importance

  • a measure of progress at sprint level
  • provide an opportunity for all stakeholders to see progress

Often project stops happen because there’s not enough software to show or people start to believe stakeholders are not interested. Product owners and scrum masters should work hard not to let this happen. How can a feeling of delivering value be supported if that value is never being measured.


  • Informal meeting, typically a demo in order to gain feedback and additional information
  • Preparation should be minimal and the meeting should be as light-weight as possible
  • One of the main objectives of the showcase is to review progress against the iteration goal and team commitment


What is backlog grooming in Scrum?

dynamic refinement of the backlog

when the product owner (and team) regularly review items on the backlog to ensure the backlog contains the relevant items, that they are prioritised, and that the items at the top of the backlog are ready for delivery.

  • removing user stories that no longer appear relevant
  • creating new user stories in response to newly discovered needs
  • re-assessing the relative priority of stories
  • assigning estimates to stories which have yet to receive one
  • correcting estimates in light of newly discovered information
  • splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration


Sprint planning in Scrum

Sprint planning produces a sprint goal and a sprint backlog

  • Sprint backlog: a list of the product backlog items the team commits to delivering, and those should be estimated
  • it is the team who says how much they can do in each sprint
  • Example: ‘implement basic shopping cart functionality including add, remove and update quantities’.