How Do You Decide How Long Things Will Take (in a SCRUM Shop)?

Subject: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
From: "Jerry Kindall" <j -dot- kindall -at- tecplot -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 18 Jun 2009 12:19:41 -0700

Yannia,

I feel your frustration. It sounds like your manager has not fully
committed to Scrum but is rather trying to maintain control over the
process. This is common in organizations that have not fully committed
to agile concepts, for example, giving the team the authority to match
their responsibility. Teams are supposed to self-organize and manage
themselves. Old-school managers often struggle to find their role in
such a process -- especially micro-managers. If the team manages
itself, what's left for your manager to do?

In Scrum, as you probably already understand, it is not the product
manager's job to provide or even influence estimates. The people who
will be doing the work provide the estimates. You are the documentation
expert on the team, so your estimates for documentation stories and
tasks MUST be taken as authoritative. It's just not going to work
otherwise.

The development team (including you but NOT him) must have the autonomy
to plan and estimate the stories for a given sprint. Otherwise, the
team will have difficulty committing wholeheartedly to ("owning") the
work, which undermines morale, trust, and motivation, and will almost
certainly lead to failure of the project in the long run. A
dysfunctional Scrum methodology (which is what you have) also undermines
overall trust in management, who are saying one thing but doing another.

It is entirely reasonable for you to express uncertainty about your task
estimations at this early stage in your job, and you shouldn't to be shy
about pushing back. As you become more familiar with the product and
your typical tasks, you will naturally become better at estimating, but
you can and should stand up for your estimates even now. Working under
this guy sounds like it could be miserable whether you assert yourself
or not, so you might as well assert yourself -- it will be better for
the project.

I realize it can be difficult to do this at a new job with such a
hands-on manager, but your manager REALLY needs to understand that it is
not his place to critique your estimates. You have had Scrum training
-- has he not? In that case, perhaps you can (discreetly) help him
understand better his role by (privately) asking questions about the
process. "I thought Scrum said to do it X way, what is your
understanding?" By gently reminding him that you're supposedly doing
Scrum, you may be able to lead him to actually doing Scrum. :-)

In the meantime, there are tactics you can use within Scrum to "manage
upward." For example, you can sometimes timebox tasks to good effect.
If your product manager wants you to only spend 8 hours on a given task,
and you are not sure you can complete it in that time, perhaps you can
instead commit to delivering a draft in that timeframe, and he can then
decide whether there is value in having you polish it further, or
something of that sort. (I realize this won't work for all kinds of
tasks.)

You could also suggest using spikes to reduce the uncertainty. If you
don't know how long something will take, estimate how long will it take
you to refine your initial estimate to your manager's satisfaction. He
can decide whether it is worth you taking a few hours to do the
necessary research to give him a more accurate estimate on the main
chunk of work.

Scrum can work for documentation if you're embedded with the rest of the
team. If you're an integrated part of the team, you can know when a
feature is ready to be documented, who has been working on it (i.e, who
your SMEs are), and during planning, you can push developers to indicate
which stories may have documentation impact. Others have mentioned that
freezing UI as early as possible is important. You can't make sure this
happens if you're not on the development team.

Good luck; your situations sounds like a bigger challenge than most.
Still, at least they have a methodology they're trying to follow, which
is better than some companies I've worked with. :-)

--
Jerry Kindall, SDK Technical Writer
Tecplot, Inc. | Enjoy the View
Bellevue, Washington, USA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices.
http://www.doctohelp.com/SuperPages/Webcasts/

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/ for more resources and info.

Please move off-topic discussions to the Chat list, at:
http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat


Follow-Ups:

Previous by Author: RE: Saving creates an internal error message
Next by Author: Flare question: inserting document title in document header (Word Output)
Previous by Thread: Re: How Do You Decide How Long Things Will Take (in a SCRUM Shop)?
Next by Thread: The Tech Writer as Smuggler


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads