Class 3 - Agile Business Practices Flashcards
What are the steps involved in creating a sprint plan?
- Create a sprint goal
- Report the project velocity from the last sprint
- Determine all potential user stories for the sprint, break them down into tasks
- Developers must create estimates for each task
- After estimates have been made, revisit chosen user stories
- The development team must sign up for tasks
True or False: It is best to have the scrum master assign tasks to the development team to assign tasks efficiently.
False. Preferably, tasks should be self-assigned
Sprint Velocity
Number of story points completed over a sprint. A measurement of the work that can be taken on and finished over the length of a sprint.
True or False: Partially finished tasks count towards sprint velocity.
False. Partially finished tasks do not count towards velocity. It is better to complete 80% of your sprint tasks entirely than having every task 80% done (no completed tasks).
Velocity-driven Development
Using previous sprint velocities combined with the amount of work completed in previous sprints to plan for the next sprint.
Release Planning
Includes:
- User stories
- Story points
- Velocity
- Release burndown charts
Iteration (Sprint) Planning
Includes:
- Tasks
- Hours
- Task Boards
- Burndown charts
Release Burndown Chart
A graph representation of the number of story points remaining after each sprint. It reflects both progress and changes to story points. It can be used to see if a project is spinning out of control.
How should the time to complete a task be estimated?
You can use the Central Limit Theorem to compute the expected time to complete a task by using the most probable time, an optimistic time, and a pessimistic time. This will give you a better estimate than using a single time estimate that may be inaccurate.
What are the 4 Agile Values?
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile Value: Individuals and interactions
- Trust motivated individuals
- Have face-to-face conversations
- Self-organizing teams work the best
- Team adjusts their behaviour
- Promote sustainable pace
Agile Value: Working software
Working software is the main measure of progress. Prioritize continuous, frequent delivery of value
Agile Value: Customer collaboration
Focus on satisfying customers early. Customers and developers need to work together to create a quality product.
Agile Value: Responding to Change
The development team should welcome changing requirements, even late into development. They should also prioritize the most important work (engage in the art of maximizing work not done)
XP Practices
Extreme Programming practices include:
- Fine scale feedback
- Continuous process
- Shared understanding
- Programmer welfare
Fine scale feedback
Includes:
- Pair programming
- The Planning Game
- Test Driven Development
- Whole Team (product owner)
The Planning Game
A meeting that occurs at the beginning of a sprint. The development team and customer get together to discuss and approve a product’s features. At the end of the planning game, developers plan for the upcoming iteration and release, assigning tasks for each of them
Whole Team (product owner)
Person who is familiar with the client’s requirements. They aim to minimize the physical distance between managers, testers, technical writers, etc.
Continuous Process
Includes:
- Continuous Integration
- Design Improvement
- Small Releases
Shared Understanding
Includes:
- Coding standards
- Collective code ownership
- Simple design
- System metaphor
Programmer Welfare
The development team is working at a sustainable pace (i.e. do not exceed 40 hours of work per week)
What are some potential communication barriers in software development?
- Language
- Assumptions
- Hasty judgements
- Time and place
- Gestures
- Status
- Topic
- Style
What are the different communication methods that can be used for communication between development teams and clients?
- Voicemail
- Phone
- Chat/Discussion Forum
- Video Conference
- Face-to-face meeting
Waterfall Model
A widely used approach in software engineering that follows a sequential and linear process. This approach is inflexible and does not leave room for revision
Spiral Model
What are the main risks that arise is software development?
- Scope risks
- Technology risks
- Customer (stakeholder) risks
- Personnel risks
Analysis Paralysis
Project stalls in its specification phase, often due to clients or product managers over-analyzing requirements
Cart before the horse
When a team spends too much time developing features that are not required at the moment and not enough time on developing critical features
Groupthink
People tend to follow the general opinions of a group, regardless of whether or not their own individual opinions are different. Their opinions would be different without the influence of the group
Silos
Occurs when teams lose touch with each other and communication is limited, which can lead to the development of counterproductive strategies and product features
Vender lock-in
Occurs when a dev team creates a product that relies heavily on a single technology, which can be problematic if the technology cannot cover what is needed, becomes outdated, or cannot adapt to change
Over-engineering
Occurs when extra or needless features are added to a product, making it confusing for the majority of users
Gold Plating
Occurs when so much effort is put into one part of a project that it reaches a point of diminishing returns
Viewgraph Engineering
Occurs when a team has to spend more time working on documentation, presentations, or reports than the project itself
Fire Drills
Occurs when the development team does very little work throughout most of the project and then makes a big push towards the end of the project, resulting in overtime work to meet deadlines
Heroics
Occurs when the development team ends up relying on only one person’s technical skills to get the project done
Death March
Occurs when the development team and the management team are at odds
Micromanagement
Occurs when a manager is very controlling and wants to be involved in every detail of a project, no matter how small. The manager needs to constantly know what their developers are doing
Seagull Management
Occurs when a manager is only present when problems arise or right before deadlines. This results in an otherwise absent manager swooping in, dumping a lot of information or requests on the development team, and then disappearing again
Loose cannons
An unpredictable person (or thing) who can negatively affect other, unless it is managed somehow. In software engineering, loose cannons tend to be people who make significant project decisions without consulting the rest of the team
Intellectual Violence
A person who asserts their opinion on every topic and impedes progress by questioning every decision and action or using their advanced knowledge in an area to intimidate or look down on other team members. They repeat their opinions so much that the rest of the group concedes to them to avoid confrontation
