|
Many of us have
experienced projects that drag on much longer than
expected and cost more than planned. Companies
looking to improve their software development
processes are now exploring how Agile can help their
Enterprise more reliably deliver software quickly,
iteratively and with a feature set that hits that
mark. While Agile has different "flavors",
Scrum is one process for implementing Agile.
This newsletter is one in a series of
newsletters that will discuss the Agile Scrum
process and will end with variants of Scrum that can
be used to aid in improving your software releases.
Here are the prior newsletters in this series:
30 Day Sprints
Agile differs from
standard Waterfall development in that development
has a smaller timeframe with a smaller feature set.
Agile Scrum implements releases every 30 days
(called 30 day sprints). Upon completing a
sprint, you can move the software to production (if
production-ready) or move into another 30 day sprint
to implement additional features.
Pragmatic Agile Development (PAD) and Agile
Scrum
It is important to
note that the way we use Agile Scrum varies from a
purist version of Scrum as we have made
modifications to Agile Scrum to work well for our
development environment. Our version of Scrum
is called Pragmatic Agile Development (PAD) and
differs from a more purist Scrum implementation in
these ways:
-
Scrum Planning - In Scrum,
planning for an upcoming sprint is accomplished
in 1 day, in PAD the planning spans 1 week.
This is because we write more detailed
specifications than a purist Scrum does (see
next bullet item).
-
User Stories vs. Specifications
- In Scrum, requirements are written on index
cards (called User Stories) and does not contain
prototypes or detailed explanations of the
feature set. In PAD, we spend time
detailing the requirement specifications with
prototypes to ensure that time is well spent on
the feature, reducing rework.
-
30 Day Sprints - In Scrum,
development is done in 30 calendar days.
In PAD, development is done in 30
working days, skipping holidays.
This provides us with more evenly distributed
sprints.
-
Team Composition - In Scrum,
developers are expected to perform all duties
(analysis, design, coding, test case
development, execution, and documentation).
In PAD, developers help with analysis and design
and perform all the coding. We have
specialized team members (Software Quality
Engineers) for test case development and
specialized team members for documentation.
We do this because our experience has shown that
we need specialists in these areas.
The goal of software development is to deliver your
software quickly and with high quality, so tweaking
a methodology to meet your needs makes sense.
Product Backlog
As your existing clients request new features or as
you come up with new features that make the product
more marketable, these items are called the
Product Backlog. In the PAD
Scrum Planning week, you will set the goal for the
sprint and prioritize product backlog items to
determine which ones can fit within the sprint.
Scrum Kickoff and
Planning Week
In the purest version of Scrum, you
have only 1 planning day for the sprint and
requirements are written on index cards (called User
Stories). We believe this is not enough time or
detail to deliver quality features, as we have shown
that taking the time to fully detail the feature
saves time once the client (or your internal team)
receives the features, it takes less re-work. So you
should devote a week to planning.
Each release (or sprint) will begin with a PAD
Planning Week. The first day of the PAD Planning
week will begin with defining the goal for the
sprint and identifying features you wish to have in
the release (from the product backlog), in priority
order.
In the purest version of Scrum, releases are done in
30-day sprints. The 30 days are calendar days, so
with holidays and weekends, this may equate to 19 to
23 working days. We have found that
sprints are best implemented in 30 working day
sprints (excluding holidays), as this provides more
evenly distributed sprints. The 30-day sprint
begins after the PAD Planning week concludes.
During the first day of the PAD Planning Week, each
team member will identify the number of hours they
can contribute to the sprint, allowing you to
determine the maximum velocity for the sprint
(velocity simply means the number of hours that can
be worked in the sprint). By knowing the maximum
velocity, you can determine what features will fit
in the sprint. After the high level features are
identified in the first day of PAD Planning, you
will assign specific work order numbers to each high
level feature and assign a set of work orders to
each team member.
The team members will spend the week defining the
detailed requirements for their assigned work
orders. Note: Work Orders are simply a hard copy
document of each functional specification.
User Interface Design Guidelines
Because you will have multiple team members
creating requirements, it is critical for your team
to define your user interface styles in a style
guide and ensure all your team members adhere to
those standards.
Decomposing Work Orders
Since sprints are limited to 30
working development days, you will be forced to make
hard decisions about the features that can fit into
the sprint. When you are assigned a work order for a
feature of the sprint, you should decompose the
feature into multiple work orders so that you can
prioritize specific pieces of the feature.
For example, let’s assume that you are redesigning
your user interface for a more pleasing look and
feel, and the aesthetics are the most important
issue for the sprint. You also would like the
screens to be more user-friendly, so you have some
issues you wish to address (like prompting to save
changes when changes are made and they switch
between tabs on the screen). In this case, you
should decompose these into 2 separate work orders
(one for the aesthetics and another for the tab
switching). By doing this, it allows you to
prioritize the tab switching lower than the
aesthetics.
User Stories vs. Work Orders
As mentioned, we favor work orders over a user
story. Here is an example of a user story
written on an index card:
Here is an example of a work order, notice how much
more detail is presented and how having a prototype
of the item you are delivering reduces ambiguity of
the feature:
If you would like an example of a work order,
download one here:
http://www.pragmaticsw.com/Template_WorkOrder.doc.
Other templates for the PAD process are available at
http://www.pragmaticsw.com/templates.
What's Next?
Upcoming newsletters will discuss the following
topics:
-
Agile Scrum - The 30 Day Sprint
and the Daily Scrum
Meeting
-
Agile Scrum - Reporting and
Metrics
-
Agile Scrum - Retrospectives
-
Agile Scrum - Site specific
variants of Scrum
|