Nitty-gritty detail of updating Scrum artifacts
- Many of the Scrum books describe the process of how Scrum works very
well, but few seem to include the Scrum artifacts and how to use
them. What I really want is the nitty-gritty details of how to use a
spreadsheet program to track project detail. Bear in mind that I am
new to this. I have search the archives but did not find a
The three artifacts for Scrum are the Product Backlog, Sprint
Backlog, and burn down chart. For the product backlog, I enter all
of the task that might be done. This spreadsheet would contain:
ID - some independant unique ID.
Description - description of of the task.
Person - person doing the task.
Estimate - estimate of the task.
Sprint - the sprint the item is assigned to.
Person, estimate, and sprint are assigned only when the task is
entered into a sprint.
As for the product backlog, I copy the items into a separate
spreadsheet and create a bunch of columns to represent the days in
the sprint. I then fill right on the estimates so that they copy the
estimates value to the end of the sprint. As developers work on the
task, they remove hours per day until they are done. The graph will
reflect the daily completions. Howver, I get stuck with the
1. Product Backlog becomes much too long. Do people add a status
column so that they can filter out items that are done?
2. Suppose developers notice that a task actually take shorter than
estimate, how is this handled? Example: developer estimate task A
will take 16 hours. It is marked as 16 hours remaining on Monday.
The next day, the developer works on it and realizes that it is
actually a 4 hour task, does the developer just change the hours
remaining to zero on Tuesday (I assume yes)?
3. Suppose the developer notice the task actually take longer. Does
the developer actually add hours to the hours remaining on the day
that it was discovered?
4. One question often asked is, do we have enough work for each of
the developers. Using the person and the estimate, one can calculate
how many hours each person is working on in the sprint. However,
estimate are likely to be off, and so may be the task should be
assigned to someone else if one person's plate becomes too full.
Should I add an actual column next to the estimate that start out
with the estimate value but is revised as the project progress? Is
there a better way of doing this?
5. A similar quesition is to track estimate vs actual. The idea is
that we can check if we are experiencing a pattern where we
consistently underestimate or overestimate. Does anyone have any
idea how to track this? Separate est and actual columns, etc.
- When I read about an organization with rampant context switching,
siloing and resource fragmentation, I believe it is management's
responsbility to figure out how to address the organizational
dysfunctions rather than blame the developers for not being able to
commit to what they can get done in short time frames under such
To say that the problem appears to be that the developers are slacking
off exhibits so much arrogance on the part of management, my gut
reaction is to suggest that if management has no more problems to
solve and yet the development throughput is unsatisfactory, then maybe
the organization needs less managers and more developers.
On 7/4/06, Wolfgang Schulze Zachau <wolfgang@...> wrote:
> The unfortunate lad reports to a different team, and I am allowed to make
> use of approx. half his time.
> I don't need to suspect. I *know* they all do things that are unrelated to
> sprint. This is due to all of us having to do day-2-day IT support for
> approx. 50-60 other staff (who range from almost complete computer
> illiteracy to somewhat advanced homw users), plus everyone has their
> personal career development objectives, which they need to spend 4 hours a
> week on doing.
> The support work is on average not enough to keep a full man busy, so we
> have decided to rotate this around, then at least everybody gets 4 days of
> relatively uninterrupted work per week.
> Have you sat
> > down with Jimmy and his partner and pointed out that they are
> > failing to meet their commitments, and asked why?
> Yep, I have. And that's when the excuses come alive. Which is why I wanted
> them all to report back how exactly they are using their time when not
> working for the sprint.
> There used to a habit here that other staff would just walk up to a member
> of the IT team, state their demands/requirements/wishes and expect things
> get done on the spot (supported to some degree by the MD himself). I have
> pretty much stopped that and now at least these folks either go through me
> or they log their work requests in the (ever popular) bug tracker, so that
> we can prioritize them and then schedule them.
> But then, we are an e-commerce company, our IT systems are the very blood
> that keep this company alive. There are numerous justified occasions where
> emergencies need to be responded to right away. I simply want them tracked.