Eliminate warehouse (was Tracking actual efforts for unexpected tasks)

[Alexander Aizikovsky]

The word 'backlog' sounds alien to agile process. It suggests that
there is a pile of things to process. Somebody spent time on its
creation and we know that some items from the backlog will never be
done. They are clearly waste. What was the point to create them?

Maybe it's just legacy of waterfall? Consequence of a false assumption
that we need to know as much as possible about what needs to be done
before we actually do something?

Analogy with parts delivered to Toyota's assembly line just in time
they are needed looks very attractive to me.
Eliminate warehouse of bugs and you don't need a bug tracking system.
Eliminate warehouse of features to be done and you don't need neither
backlog nor burndown chart.

Is it practical to assume that description of a feature to develop is
created when the team is ready to work on it?
Has anybody had practical experience working with no warehouses?

Thanks,
Alex Aizikovsky

[Vasyl Keretsman]

> The word 'backlog' sounds alien to agile process. It suggests that
> there is a pile of things to process. Somebody spent time on its
> creation and we know that some items from the backlog will never be
> done. They are clearly waste. What was the point to create them?
>
> Maybe it's just legacy of waterfall? Consequence of a false assumption
> that we need to know as much as possible about what needs to be done
> before we actually do something?
>

Regarding Scrum all client (business) requests must not be ignored.
They are placed into the Product Backlog by Product Owner. At the
moment of creation you don't know whether this feature will be done or
not. All requests are important but only those with the highest
priorities go first into development. I guess it is responsibility of
Product Owner to prioritize them properly before each sprint after
discussions with clients.

I don't think it is waste of time. It does not mean an item has to be
100% clearified when it is added to the Product Backlog. It may look
like one sentence request "User should be able to view the X report"
for example, which is not time consuming to add.
However, an item should be made clear for developers before it goes to
the development (added into the Sprint Backlog).

> Analogy with parts delivered to Toyota's assembly line just in time
> they are needed looks very attractive to me.
> Eliminate warehouse of bugs and you don't need a bug tracking system.
> Eliminate warehouse of features to be done and you don't need neither
> backlog nor burndown chart.

The aim of all software development methodologies is predictability.
If you do not track anything how you can be sure about what you are
doing and your current stage.
If you eliminate bug tracking you hide bugs, which must be fixed.
Hiding bugs does not do your system bugless.

I think Scrum does not conflict with the Assembly line idea.
As i can see assembly line is the Sprint backlog(development). When an
item needs to be done it goes into development.

Vasyl

[Alexander Aizikovsky]

On Mar 25, 11:28 am, "Vasyl Keretsman" <vasi...@gmail.com> wrote:
> Regarding Scrum all client (business) requests must not be ignored.

None of them should be ignored, but do all (or any) of them need to be
on backlog?

> They are placed into the Product Backlog by Product Owner. At the
> moment of creation you don't know whether this feature will be done or
> not. All requests are important but only those with the highest
> priorities go first into development. I guess it is responsibility of
> Product Owner to prioritize them properly before each sprint after
> discussions with clients.

Some of them don't go to the iteration. Do they need tracking?

> The aim of all software development methodologies is predictability.

This is a very strong statement.
I would argue that the goal of software development is working
software satisfying business needs.
Agile approach suggests a way of satisfying business needs which is
much easier achievable than predictability.

> If you do not track anything how you can be sure about what you are
> doing and your current stage.

The highest priority feature.

> If you eliminate bug tracking you hide bugs, which must be fixed.
> Hiding bugs does not do your system bugless.

Though they look very much alike to me, It was a mistake to mix
backlog and bug tracking in one paragraph.
See 'Bugless development' thread.

Thanks,
Alex

[Vasyl Keretsman]

> > Regarding Scrum all client (business) requests must not be ignored.
> None of them should be ignored, but do all (or any) of them need to be
> on backlog?

All of them should be in the Product Backlog.

>
> > They are placed into the Product Backlog by Product Owner. At the
> > moment of creation you don't know whether this feature will be done or
> > not. All requests are important but only those with the highest
> > priorities go first into development. I guess it is responsibility of
> > Product Owner to prioritize them properly before each sprint after
> > discussions with clients.
> Some of them don't go to the iteration. Do they need tracking?

Some of them don't go into the iteration immidiatelly, but they may be
included in the further iterations. It is up to client to decide what
is more important before each iteration.

Just in case, i am talking about two backlogs - Product and Sprint.

>
> > The aim of all software development methodologies is predictability.
> This is a very strong statement.
> I would argue that the goal of software development is working
> software satisfying business needs.
> Agile approach suggests a way of satisfying business needs which is
> much easier achievable than predictability.

Ok sorry, it is my bad wording about aim and predictability. I've
meant that all software development methodologies trying to achieve
management in a predictable way, even in agile. The goal is
definitely "working software satisfying business needs".

>
> > If you do not track anything how you can be sure about what you are
> > doing and your current stage.
> The highest priority feature.

Just in case i am with you.
Do you mean that as long as a feature does not go to the nearest
iteration we do not need remember it? But what if this feature can
become important for the 3rd iteration for example? Having such thing
like Product backlog helps you do not miss client requests.

Vasyl

[Yuriy Mann]

> Eliminate warehouse of bugs and you don't need a bug tracking system.
> Eliminate warehouse of features to be done and you don't need neither
> backlog nor burndown chart.

Well, look at this from another point of view: bug tracking and
product backlog are means of synchronization. Between the moment when
someone comes up with an idea about new feature/improvement/rework in
the product or finds an apparent bug, and the moment when the team
finds resources to investigate and resolve/reject the issue. In real
life nobody is able to keep in mind all useful knowledge about how a
product can be improved - even those who claim they remember anything.
People also rotate in an average software teams.

Best regards,
Yuriy

[alexeyk...@gmail.com]

On Mar 26, 2:49 am, "Alexander Aizikovsky" <aiz...@gmail.com> wrote:
> On Mar 25, 11:28 am, "Vasyl Keretsman" <vasi...@gmail.com> wrote:> Regarding Scrum all client (business) requests must not be ignored.

> > If you eliminate bug tracking you hide bugs, which must be fixed.

> > Hiding bugs does not do your system bugless.
>
> Though they look very much alike to me, It was a mistake to mix
> backlog and bug tracking in one paragraph.
> See 'Bugless development' thread.

i think bug and feature backlogs have slightly different nature:
bugs that are found inside a sprint should be fixed asap ('stop the
line' lean rule) and the easier is the tracking strategy the faster it
can be fixed
the need to fix such bugs asap have several reasons:
1- it is easier to fix the code that you've been just changing - you
still can remember the low-level details so won't waste too much time
2- unfinished (buggy) bugs/features are usually quite bad impediments
to project's progress, because
- bug reviews/prioritization sessions will become mission-impossible
sessions,
- development of new features (on top of the buggy ones) is made
harder - always adding fixing time to clear development of new
features,
- good-enough estimates can't be made due big number of unknowns in
the code
- bug count will tend to grow making things only worse...
3- sprint result is NOT a potentially working incremental

feature backlog is another thing for me - it should be there so that
adequate understanding of system architecture can be elaborated,
although i confirm that too long backlogs have the same drawbacks as
too long bug lists - they make all processing activities (planning in
this case) harder
my experience shows that a feature backlog of 2-3 sprint long is quite
informative for system evolution yet still manageable.

// Alexey

[Alexander Aizikovsky]

On Mar 26, 12:02 am, "Vasyl Keretsman" <vasi...@gmail.com> wrote:
> Just in case i am with you.

Thanks ;)

> Do you mean that as long as a feature does not go to the nearest
> iteration we do not need remember it? But what if this feature can
> become important for the 3rd iteration for example?

Once we had a change request DB. It was growing much faster than we
were able to deliver.
Special planning board with representatives of all the stakeholder
groups has discussed priorities of the change requests. 95% of them
never made it to development. Sounds like waste to me.
Overall, my experience is that chances of a feature not to be
developed at all exponentially depend on its initial priority.
If the feature is scheduled for a current iteration, it's 90%, for the
next iteration it's 50%, for the 3rd - 10%. Numbers of course aren't
precise. This is just my feeling.

>...Having such thing

> like Product backlog helps you do not miss client requests.

I think, that when the trust is built, your client will not allow you
to forget about her next top priority. And in real life the current
top priority is often different from the yesterday's one.

If every iteration is releasable, nobody needs a backlog. Is it
possible to release every 2 weeks? People claim it is. How to achieve
this level of dev process? Don't know yet. But I would like to search
and to try.

Are you still with me? ;)
Cheers
Alex

[Serhiy Yevtushenko]

Hi, Alex.

I think one more aspect of the product backlog is missed.
The point of product backlog is to have longer time vision of product developement (strategic direction). Product backlog is analogous to the XP Release Plan.
So, even if iteration is releasable, product backlog (release plan) will be important in order to have some direction.
Also, pay attention that business people (marketing), etc, should make their plans also.
They may have conferences, exhibitions, etc, the preparation for which requires time.
Therefore, they need some understanding of the direction.
Product Backlog and Release Plan also serves for communication purposes inside organization and longer time planning purposes.

Serhiy Yevtushenko

2007/3/26, Alexander Aizikovsky <aiz...@gmail.com>:

[Tim Yevgrashyn]

I'll join to Serhiy.

The Product Backlog is a long-term document (or a chain of documents) that helps to plan development of the product for months and more, from release to release. All Errors and Ideas reported by users/customers/sales and other stakeholders are expected to be there. Otherwise you will loose them.

Product owner (with other stakeholders) have to prioritize them regularly. And only first XX items need description in order to let the Team to pick them for a next sprint.

 

Just as example from our "product people life" - they have such list of Errors/Ideas and some crazy ideas have got stuck there for years. But in the same time, such list gives us possibility quickly include requests from valuable users into the next sprint and in the same time plan Milestones and Releases for the whole year.

 

 

I'll also join to Aleksey.

Please don't mix bugs and defects. It's better to separate such terms. I do that in this way:

- Bugs is something developers/testers found during internal acceptance session and they are usually fixed within same sprint.

I.e. they are part of "DONE" condition and can't stay "alive" for a long time ;-)

 

- Defects reported by users/customers and other stakeholders. It just means that something work not as user expected. In most cases it is not developers fault, but rather a question of business analysis.

Defects are the same tasks as new features ;-)

 

 

So, my POV is following:

All issues (new features, defects reported to support and even non-fucntional needs such as refactoring and etc) have to be placed in the Product Backlog. The ProductOwner is responsible for maintaining it, splitting into Releases (if needed) and prioritizing. Only the tip of the list has to be prioritized precisely and supplied with descriptions.

 

Team selects issues for a sprint from the top. Clarify them; plan; adjust estimations and implement. Of course Team makes all items "100% done" and "potentially shippable" and etc. ;-)

 

--
With best regards,
Tim Yevgrashyn

[Alexander Aizikovsky]

Hello Serhiy,

On Mar 27, 5:08 am, "Serhiy Yevtushenko" <syevtushe...@gmail.com>
wrote:

> The point of product backlog is to have longer time vision of product
> developement (strategic direction). Product backlog is analogous to the XP
> Release Plan.

You are absolutely right about shared vision of a product. No doubts
it's extremely important for success.
Is backlog the best way of sharing the vision? Not sure.

> So, even if iteration is releasable, product backlog (release plan) will be
> important in order to have some direction.

I am trying to sell the crazy idea of not tracking a backlog, assuming
that each iteration is released. So release and iteration plans are
the same.

> Also, pay attention that business people (marketing), etc, should make their
> plans also.
> They may have conferences, exhibitions, etc, the preparation for which
> requires time.

To make a killer impression at an exhibition creative developers can
come up with very inexpensive features if they share the vision of
product owner.
And if their hands are not tied up with the plans and unimplemented
backlog items :)

[Serhiy Yevtushenko]

2007/3/27, Alexander Aizikovsky <aiz...@gmail.com>:

Hello Serhiy,

On Mar 27, 5:08 am, "Serhiy Yevtushenko" <syevtushe...@gmail.com>
wrote:
> The point of product backlog is to have longer time vision of product
> developement (strategic direction). Product backlog is analogous to the XP
> Release Plan.
You are absolutely right about shared vision of a product. No doubts
it's extremely important for success.
Is backlog the best way of sharing the vision? Not sure.

> So, even if iteration is releasable, product backlog (release plan) will be
> important in order to have some direction.
I am trying to sell the crazy idea of not tracking a backlog, assuming
that each iteration is released. So release and iteration plans are
the same.

> Also, pay attention that business people (marketing), etc, should make their
> plans also.
> They may have conferences, exhibitions, etc, the preparation for which
> requires time.
To make a killer impression at an exhibition creative developers can
come up with very inexpensive features if they share the vision of
product owner.
And if their hands are not tied up with the plans and unimplemented
backlog items :)

The point of doing release each iteration is done in some processes, in XP and Evo.
And the point of Scrum is to be able to do release after each iteration.

But release to external customers is the business decision. It may have quite different costs depending from the software distribution model.
In web applications, you may do release every day
In shrink-wrapped, the cost of release is quite high. It requires printing documentation, ,,,

Nevertheless, the high level vision is required also.
Other point - Product backlog is not commitment.
You are not tied up by the product backlog, that you are absolutely forced to do a work from the product backlog.
You can change direction after each iteration.
But this is not Scrum master or Team Decision.

The decision about changing direction is Product Owner responsibility.

Team is not tied up by the Product Backlog.
The job of maintaining and prioritizing Product Backlog is responsibility of the Product Owner.
And this is not a team decision on what to work on next iteration.
This is product owner decision.