Preface
Once a software team leaves the familiarity of waterfall and other traditional project management styles they often feel the pain of "how do I structure my work?" Fortunately, agile development uses four clear delivery vehicles to bring structure to any agile project: user stories, sprints, epics, and versions. By working with these vehicles, software teams are able to organize their work such that they can respond to customer feedback and change from the original plan of the project without feeling like the walls have crumbled around them.
The ability to change and adapt future plans based on current insights is a hallmark of agility. In this article, we'll look at how these four delivery vehicles keep programs agile.
Getting granular: user stories
In an agile framework, user stories are the smallest units of work. The goal of a user story is to deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense: they can also be internal customers or colleagues within your organization who depend on your team. User stories are a few sentences in simple language that outline the desired outcome. They don't go into detailed requirements.
User stories are often written using the following template:
Let's use a website as a simple example to create a user story.
User stories are sketched out by the product owner, then the full product team collectively decide the more detailed requirements. These are the granular pieces of work that help define the implementation items for the story and the upcoming sprint. In the above example, there are a set of tasks required to make the account feature work: database changes, new server logic, as well as new user interface components. These tasks should be fleshed out during estimation of the user story and linked in the team's issue tracker.
Fixed development cadence: sprints
In Scrum, teams forecast to complete a set of user stories during a fixed time period, known as a Sprint. Generally speaking, sprints are one, two, or four weeks long. It's up to the team to determine the length of a sprint–we recommend starting with two weeks. That's long enough to get something accomplished, but not so long that the team isn't getting regular feedback. Once a sprint cadence is determined, the team perpetually operates on that cadence. Fixed length sprints reinforce estimation skills and predict the future velocity for the team as they work through the backlog.
Two important things to recognize about Sprints:
A great tool for any scrum team are burndown charts. They clearly track progress throughout the sprint with "work remaining" on the Y axis, and "time" on the X axis. Burndown charts are a powerful motivator for the team, and they keep everyone focused during a sprint. Above all, these charts provide supporting data in discussions about the progress of a sprint.
Note: Sprints are only a part of the scrum framework. Kanban teams, by contrast, work on the next item in the backlog as capacity permits. No forecasting is required.
Stepping up: epics
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
Unlike sprints, scope change in epics is a natural aspect of agile development. Epics are almost always delivered over a set of sprints. As a team learns more about an epic through development and customer feedback, user stories will be added and removed to optimize the team's release time. This is the unique freedom a product owner gets with an agile framework, because he or she can focus on ensuring the development team is working on the most important things.
Burndown charts can also be used to visualize epics, which keep teams motivated and the executive stakeholders informed. A good epic burndown chart shows the agile nature of development. It's clear how the team is progressing as well as where the product owner added and removed user stories. Having these data points clearly visible keeps everyone on the same page and facilitates open conversation about the evolution of the product and completion forecasts. Not to mention that transparency builds trust!
Stepping out: versions
Versions are the actual releases of software out to customers. Remember, at the end of each sprint the team should be able to ship the software to customers. Versions are the curated changes the product owner actually ships.
Versions are often developed over a set of sprints, much like epics. Savvy product owners may choose to deliver an epic over several versions. An epic does not have to be fully contained within a version. By delivering an epic over several versions, the product owner can learn how the market is responding to that epic and make calculated decisions about its future direction rather than doing one giant release.
Looking at our account management scenario above, a product owner may structure the release strategy as follows:
Version scope change is also a natural part of agile development. Burndown charts keep the entire team abreast of how a version is evolving over time. Changes to a version should be discussed with the whole team to keep everyone on the same page.
Scaling up
Larger organizations will often have several agile teams working on a common program, and portfolio planning is a key piece of running agile at scale. Epics and versions lay the foundation for solid agile portfolio management at the team level. Agile portfolio management encompasses tracking programs across several teams while retaining that same level of agility in higher levels of the organization. Learn more about agile at scale in the agile portfolio section.
沒有留言:
張貼留言