The trouble with creating detailed requirements when you start a project, of course, is that by the time you get around to developing the feature you've discovered all sorts of things you didn't know when the original requirements were drafted. That's how we end up with all those change requests floating around. For some processes, that tradeoff may be perfectly acceptable. Others may prefer to trade certainty for flexibility. Some agile methodologies use this approach, by creating "user stories" to capture and track feature requirements in brief until it's time to develop them in detail, when all of the information is available to work with. This approach might work well for very small projects that can't easily bear the weight of a lengthy requirements discussion. You may be surprised at the issues dredged up by writing user सतोरिएस
Agile Technique Brief: Estimating
What this is
This technique brief discusses an agile approach to estimating the size of features for a software development project. The approach, called Planning Poker, provides a mechanism that allows the team to collaborate on an estimate that reflects their combined knowledge and experience.
Why it's useful
The approach to estimating described in this technique brief allows teams to produce useful estimates without spending a great deal of time focusing on unattainable accuracy. The approach uses relative size measurement instead of absolute duration estimates to avoid the variation introduced by different skill levels of team members developing features. The use of velocity to capture the team’s ability to develop features helps to reduce uncertainty.
How to use it
Teams can use the following steps to determine an initial estimate of duration for a project and then monitor progress toward that estimate as the project proceeds.
Establish a feature list for the project.
Gather the team together; the development members to estimate cost, the business members to estimate benefit.
Use Planning Poker to converge on an estimate for each feature. (Detailed instructions are provided in the guideline.)
Determine the desired length of the project’s iterations. The ideal length for an iteration is long enough that the team can deliver something of value, but short enough that it is not painful for the business to wait and change something. Typical iterations last between 2 and 4 weeks.
Determine an initial velocity. The best way to do this is to determine how many features the team can commit to delivering in the first iteration. Add up the story points associated with those features and use that as the initial velocity.
Divide the total story points included in the feature list by the velocity to determine how many iterations will be required, then convert the number of iterations to days or weeks depending on what is preferred by your organization. The result answer is the anticipated duration of the project.
After the first iteration, total up the story points from the features that were completed (i.e. accepted by the Product Owner). This is the actual velocity of the first iteration. Recalculate the expected duration based on this new velocity.
After the second iteration, recalculate the overall team velocity by averaging the velocity from the first two iterations.
Repeat after each iteration, monitoring the corresponding impact on the expected date that the feature list will be completed
Agile Technique Brief: Agile Planning
What this is
This technique brief provides an overview of agile planning, an iterative and feature-based approach to project planning.
Why it's useful
Agile planning is feature-based, iterative, owned by the team, and uses different levels of detail. These characteristics provide teams an opportunity to get rapid feedback on their designs and processes, apply learning from past experiences quickly, and keep their project plans simple, but effective. This approach to planning provides project teams with a means to produce features in a short amount of time in order to gain useful feedback from users, customers, and stakeholders. It also allows teams to defer decisions on detailed requirements until the feature is being developed, allowing them to apply the most current and accurate information possible.
This approach works when the team has decided to follow an iterative and incremental project approach and is most useful in situations where the product of the project can be delivered in small increments.
How to use it
There are several different layers of planning. This technique brief describes three of those levels—release planning, iteration planning, and daily planning. The following steps provide an overview of how to start planning at the beginning of a project. Assume the project has been approved to proceed and that there is a project value model with a defined project purpose, considerations, and cost-benefit analysis.
Gather the team together to refine and update the project value model with any new information and to establish a feature list.
Prioritize the feature list by determining the relative cost, benefit, and value of the features.
Determine in what releases those features will most likely be delivered. (See the Release Planning section.)
At the start of each iteration, pick features for that iteration and break them into tasks. (See Iteration Planning.)
On a daily basis, coordinate the team’s activities. (See Daily Planning.)
Repeat Steps 3–5 as appropriate.
Agile Technique Brief: Project Value Models
What this is
This technique brief describes an approach a team can use to make value-based, rational, objective decisions about what projects and features to do and in what priority to deliver them. It guides teams to:
Establish a shared understanding of the project purpose
Identify the various considerations that impact the project on a daily basis
Determine the expected costs and benefits realized by a project
Use this information to make informed decisions
Why it's useful
Informed decision-making is one of the key factors of success on projects, so it is very helpful for teams to understand the components of good decision-making. In the case of projects and features, these decisions should ideally be made on the basis of value, with the appropriate information available and at the appropriate time. The Project Value Model helps teams identify the information necessary to make value-based decisions, and organizes that information so it can be used to make decisions throughout the project as conditions change.
How to use it
Gather the team together to establish a shared understanding of the project purpose.
Establish a place to record project considerations. Use the collaboration process to create an initial list of risks, assumptions, and constraints. Add to this list whenever new items come up.
Determine your organization’s preferred approach to cost-benefit analysis, and create a spreadsheet that allows your team to quickly revise cost and benefit information throughout the life of the project, in order to determine the value delivered. Include a way of tracking assumptions related to various cost and benefit items, for quick tracing of how various cost and benefit numbers were determined.
Decide whether or not to pursue the project. Use the Purpose Alignment Model to identify how the project aligns with the organization’s strategy. Decide whether the project is worth pursuing based on its support of differentiating or parity activities. If there are any risks too large to overcome, or any constraints that cannot be met by the project, do not pursue the project.
Compare cost-benefit information with the organizational expectations and decide whether the initial instance of the project provides the expected value.
Determine the relative cost, benefit, and value of the requested features and produce an ordered features list
No comments:
Post a Comment