Project communication out to the business

[productownertim]

Hello! I'm Tim, working as a PO.

We're using Scrum by name but key elements are missing, estimating's done in hours, we don't use use cases or stories for requirements (big chunks of work are just existing change requests for bugs, maintenance basically). We're also using an offshore model so aren't co-located.
We're fairly closed off from the rest of the business at the moment in terms of communication and with our last release of the software the perception was just that it was taking forever to get out, release dates keep going back and back.

We don't have continuous integration or any unit testing/automated testing and our regression activities usually take one and half to two sprints to do. So the concept of being able to release at any point doesn't really fit for us yet.

So my first question to test the water is what sort of information do you publish out to the rest of the business relating to project progress (expected release dates for example)?

Project Burndowns?
Expected feature set?
Milestones?


Tim

[Steven Gordon-2]

The use of the words "out" and "to" in the title makes me suspicious that
there are bigger problems here.

Communication should be bi-directional, and also frequent enough that it
does not seem like the business is outside.

The issue is not what artifacts to communicate with, but how to make
communication more bi-directional, human and effective.


On Fri, Oct 2, 2009 at 4:22 AM, productownertim <thopkins@...> wrote:

>
>
> Hello! I'm Tim, working as a PO.
>
> We're using Scrum by name but key elements are missing, estimating's done
> in hours, we don't use use cases or stories for requirements (big chunks of
> work are just existing change requests for bugs, maintenance basically).
> We're also using an offshore model so aren't co-located.
> We're fairly closed off from the rest of the business at the moment in
> terms of communication and with our last release of the software the
> perception was just that it was taking forever to get out, release dates
> keep going back and back.
>
> We don't have continuous integration or any unit testing/automated testing
> and our regression activities usually take one and half to two sprints to
> do. So the concept of being able to release at any point doesn't really fit
> for us yet.
>
> So my first question to test the water is what sort of information do you
> publish out to the rest of the business relating to project progress
> (expected release dates for example)?
>
> Project Burndowns?
> Expected feature set?
> Milestones?
>
> Tim
>
>  __._,_.__
>

[Wes & Evie]

Tim,
You need to invite your 'outside' people to your daily scrum meetings and
make them inside people.  A large part (very large part) of agile of any
type is fast feedback to everyone.  Daily scrums, short development cycles,
frequent releases, etc. are all about letting everyone see where WE are as a
team to verify we are delivering the highest priority value to the customer.
 Until you are doing this you are not really doing agile (scrum or
otherwise) you are simply doing iterative development.

So start asking how can you get them involved?  Ask them if they are
satisfied with what you are delivering?  Ask if they are satisfied with when
you deliver?  Ask if the are satisfied with the quality?  If not ask them to
come and meet with the team on a regular basis to make sure the team
understands the requests.  Both groups will get a better picture of what the
other needs.

wes

On Fri, Oct 2, 2009 at 7:22 PM, productownertim <thopkins@...> wrote:

>
>
> Hello! I'm Tim, working as a PO.
>
> We're using Scrum by name but key elements are missing, estimating's done
> in hours, we don't use use cases or stories for requirements (big chunks of
> work are just existing change requests for bugs, maintenance basically).
> We're also using an offshore model so aren't co-located.
> We're fairly closed off from the rest of the business at the moment in
> terms of communication and with our last release of the software the
> perception was just that it was taking forever to get out, release dates
> keep going back and back.
>
> We don't have continuous integration or any unit testing/automated testing
> and our regression activities usually take one and half to two sprints to
> do. So the concept of being able to release at any point doesn't really fit
> for us yet.
>
> So my first question to test the water is what sort of information do you
> publish out to the rest of the business relating to project progress
> (expected release dates for example)?
>
> Project Burndowns?
> Expected feature set?
> Milestones?
>
> Tim
>
>  
>

[Robert-323]

Hi Tim,

One of the key aspects of any of the agile methods is *transparency*.
You don't necessarily want to report (or not report) on anything.
Instead, you want to make progress and other aspects of your efforts
clearly visible to the team and all stakeholders.

This notion drives engagement on the part of stakeholders and creates
wonderful *conversations* surrounding progress, trade-offs, changes,
etc.

As an effective Product Owner, you want to foster this sort of 2-way
information sharing. But that's just one dimension to your Product Owner
role. At the risk of sounding self-serving, I'd recommend you read my
book on the role of the Product Owner - find it here -
http://tinyurl.com/nxor6p. It's a broadly nuanced and complex role. One
that's a challenge to get "right" within each organizations context.

While not being a "silver bullet", it might provide some additional
guidance towards transparency and organizational communication. In lieu
of that, go google the role and read as much as you can about it. Good
luck!
Bob.

--- In agile-testing@..., "productownertim" <thopkins@...>
wrote:
>
> Hello! I'm Tim, working as a PO.
>
> We're using Scrum by name but key elements are missing, estimating's
done in hours, we don't use use cases or stories for requirements (big
chunks of work are just existing change requests for bugs, maintenance
basically). We're also using an offshore model so aren't co-located.
> We're fairly closed off from the rest of the business at the moment in
terms of communication and with our last release of the software the
perception was just that it was taking forever to get out, release dates
keep going back and back.
>
> We don't have continuous integration or any unit testing/automated
testing and our regression activities usually take one and half to two
sprints to do. So the concept of being able to release at any point
doesn't really fit for us yet.
>
> So my first question to test the water is what sort of information do
you publish out to the rest of the business relating to project progress
(expected release dates for example)?
>
> Project Burndowns?
> Expected feature set?
> Milestones?
>
>
> Tim
>

[James Martin-7]

On Fri, Oct 2, 2009 at 10:22 PM, productownertim <thopkins@...> wrote:

> Hello! I'm Tim, working as a PO.
>
> We're using Scrum by name but key elements are missing, estimating's done
> in hours, we don't use use cases or stories for requirements (big chunks of
> work are just existing change requests for bugs, maintenance basically).
> We're also using an offshore model so aren't co-located.
>

Estimating in hours instead of story-points is not the end of the world,
although I suspect it's the least of your worries. If you haven't already I
would really recommend you read Mike Cohn's book "Agile Estimating and
Planning"[1]: He provides some excellent worked examples of using "ideal"
time periods for estimation and planning.

This book also covers some nice examples of progress reporting and
techniques for engaging the areas of your organisation that are not directly
imbedded in the team.


Thanks,
James.


[1] http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415