Domain 5 Agile Adaptive Planning
Sebutkan dan jelaskan hal-hal dibawah ini:
Tools and Techniques :
Affinity estimating
Affinity Estimating is a technique many agile teams use too quickly and easily estimate a large number of user stories in story points. This is a great technique if a project has just started, and has a backlog that hasn't been estimated yet, or in preparation for release planning.
Page 281.
Agile discovery
The concept of“agile discovery” is an umbrella term that refers to the evolution and elaboration of agile project plans in contrast with an up-front, traditional approach to project planning. It covers topics such as:
» Emergent plans and designs versus predictive plans and designs
» Pre-planning activities to gather consensus on the best approach to follow
» Backlog refinement (grooming) and how it is performed
» Estimating uncertain work versus certain work
» The characteristics of new product development versus well-understood and repeatable projects
Agile Discovery Phase is a process of focusing on each piece of the project and nailing down all the details of it. Your project is the last thing to be left with unsaid details and misinterpretation.
Agile Discovery Phase is all about getting to know your target audience needs, writing down requirements and creating a full scope for the project. It’s the first basic step to obtain a reliable budget and development timeline estimation. It’s a solid plan for your project that helps you avoid unexpected surprises (such as bigger costs, extended timeline) during the actual development.
Page 253
Architectural spike
An architectural spike is a technical risk-reduction technique popularized by Extreme Programming (XP) where you write just enough code to explore the use of a technology or technique that you're unfamiliar with.
“Spikes” are periods of work undertaken to reduce threats and issues, and“architectural spikes” are iterations used to prove a technological approach. The spikes are blended into the release planning processes.
An architectural spike is a short, time-boxed effort dedicated to “proof of concept”—in other words, checking whether the approach the team hopes to use will work for the project. For example, we might say, “We’ll spend one week testing the performance of the native database drivers before making a decision on connectivity” Or,“We need to test the viability of using straw as a renewable home insulation product.” The idea is to explore the viability of an approach or candidate solution in a short time frame. We are seeking to answer questions like “Can we do it?” or address stakeholder concerns like “Prove it will work!” to see if we can use the approach we have in mind.
Page 293.
Agile sizing and estimation
Agile estimation is about evaluating the effort required to complete each work item listed in the prioritized backlog, which, in turn, helps improve sprint planning. Estimates can be hard to grasp. How should a company know the amount of time it will take to complete a product backlog item so far in advance? How can they account for unforeseen impediments that arise? This is where Agile estimation techniques come to the rescue.
From Agile project cost estimations to how long it will take to deliver, estimations are part of the daily grind. The project is likely to go off track without accurate estimations in terms of budget and time.
Backlog grooming/ refinement
Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
Value-based analysis and decomposition
Agile planning is based on value-based analysis. This is the process of assessing and prioritizing the business value of work items and then planning accordingly. This process continues over the full life cycle of a project, impacting how we scope, plan, schedule, develop, test, and release work. At every stage of the project, we are asking, “What is the business value of this item or practice?” and “What items in this set have the highest business value?” We then prioritize the work to deliver the highest-value items first.
Value-based decomposition
Value-based decomposition is a continuation of the process of value-based analysis—here, the team elicits requirements from stakeholders; groups, break down, and ranks those requirements; and then pulls the prioritized requirements into the development process. The figure below shows what this process might look like on a typical agile project.
Daily stand-ups
A daily stand-up meeting is a short organizational meeting that is held each day. The meeting, generally limited to between five and fifteen minutes long, is sometimes referred to as a stand-up, a morning roll-call, or a daily scrum.
Ideal time
An ideal time estimate tells us how long a task will take if all other peripheral work and distractions are removed. It assumes that the work item being estimated is the only thing that is being worked on, that there will be no interruptions, and that we have everything we need to complete that work item—in other words, we aren’t waiting for someone else to deliver other work or provide information.
Page 263
Iteration and release planning
Agile release planning is a product management method where you plan incremental releases of a product. It differs from traditional software planning where you focus on major releases.
In Agile release planning, you prepare for staged releases and then break those down into several different sprints or iterations.
Product roadmap
A product roadmap is a shared source of truth that outlines the vision, direction, and progress of a product over time.
Progressive elaboration
Progressive elaboration is a process of the Project Planning Process Group, It refers to the ongoing improvement of a project plan based on new learnings and insights obtained during the project lifecycle.
Relative sizing/ story points/ T-shirt sizing
Relative (estimation) sizing is one of the several distinct flavors of estimation used in Agile teams, and consists of estimating tasks or user stories, not separately and in absolute units of time, but by comparison or by a grouping of items of equivalent difficulty.
Story points are a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story.
T-shirt sizing is a project estimation and capacity planning tool that helps you track how much time or effort an initiative will take. To do this, you assign each project or task a t-shirt size—from Extra Small to XXL—to represent that task's relative effort.
Requirements reviews
Requirements review in Agile: Ensuring consistency and spotting defects
Agile testing teams can improve their requirements review process by ensuring consistency, carefully determining testability, and spotting missing connections.
A requirements review is a manual process that involves people from both client and contractor organizations. They check the requirements document for anomalies and omissions. The review process may be managed in the same way as program inspections (see Chapter 22). Alternatively, it may be organized as a broader activity with different people checking different parts of the document.
Requirements reviews can be informal or formal. Informal reviews simply involve contractors discussing requirements with as many system stakeholders as possible. It is surprising how often communication between system developers and stakeholders ends after elicitation and there is no confirmation that the documented requirements are what the stakeholders really said they wanted. Many problems can be detected simply by talking about the system to stakeholders before making a commitment to a formal review.
In a formal requirements review, the development team should ‘walk’ the client through the system requirements explaining the implications of each requirement. The review team should check each requirement for consistency and should check the requirements as a whole for completeness. Reviewers may also check for:
Verifiability Is the requirement as stated realistically testable?
Comprehensibility Do the procurers or end-users of the system properly understand the requirement?
Traceability Is the origin of the requirement clearly stated? You may have to go back to the source of the requirement to assess the impact of a change. Traceability is important as it allows the impact of change on the rest of the system to be assessed.
Adaptability Is the requirement adaptable? That is, can the requirement be changed without large-scale effects on other system requirements?
Conflicts, contradictions, errors, and omissions in the requirements should be pointed out by reviewers and formally recorded in the review report. It is then up to the users, the system procurer, and the system developer to negotiate a solution to these identified problems.
Risk-based spike
A risk-based spike is a short, time-boxed effort that the team sets aside to investigate—and hopefully, reduce or eliminate—an issue or threat to the project. These short experiments to investigate risky portions of the project are a key tool for risk management.
Page 293
Story maps
A story map is a high-level planning tool that agile stakeholders can use to map out the project priorities early in the planning process, based on the information available at that point.
Page 284
Timeboxing
A timebox is a short, fixed duration period of time in which a defined set of activities or work is undertaken. If the work planned for the timebox isn’t complete when the time runs out, we stop what we’re doing and simply move the uncompleted work into another timebox.
Page 259
User stories/ backlog
User stories
A user story is defined as a “small chunk of business functionality within a feature that involves roughly 1 to 3 days’ worth of work.” (This time frame can be defined more specifically as “4 to 40 hours’ worth of work”) Agile teams typically break the product features down into user stories and write them on index cards or enter them into a requirements management tool.
Page 267
Backlog
This is a single, visible master list of all the functional and non-functional work that has been identified for the project, sorted by priority.
pag e 273
After the user stories are written, they are listed and sorted to create the user story backlog (also known as the “backlog” or “product backlog”) for the project
Wideband Delphi/ planning poker
The Wideband Delphi estimation method is a consensus-based technique for estimating effort. It derives from the Delphi method which was developed in the 1950-1960s at the RAND Corporation as a forecasting tool. It has since been adopted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts.
Planning Poker is an agile estimating and planning technique that is consensus-based. To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
No comments:
Post a Comment