Thanks for your comment. I was a bit ambiguous. When I said anything can go on the product backlog, I meant anything that is a feature of the product, rather than tasks.

Project management is something you have to do with all of the features on the product backlog, so it shouldn't be on there because you won't ever be done with project management and it won't ever be part of the end product as such.

Graphic design is similar. Although users will eventually see the graphic design, on its own it is not a feature of the product, as a graphic design without the development is of no value to the user.

Instead you express the features of the product on the product backlog and tasks like project management, graphic design, development, testing, etc are all tasks that do not need to be listed for every feature.

When you come to Sprint Planning (read the next steps in the series), you will eventually break the user stories or features down into tasks, and the "Sprint Backlog" will contain all the tasks for the section of the Product Backlog that will be delivered in the next sprint.

Hope that all makes sense!

Kelly.

Thanks,

Kelly.

Our product backlog has quite a few "epic" stories. We have asked to have them broken down, however the issue is that if we were to do so, they don't add value individually. However, if we leave them as is, they are far too large and could never get done in a Sprint (or even two or three possibly).

Next, if we could get past this, if they were to be broken down, does it make sense to remove the original epic story? I would think so, as it has now been broken down, however in doing so you lose the full picture.

I can say yes, scrum will work for you. I faced the same problem: Creative design agency, 16 members of staff. Half the dev team based in Poland and lots of smaller projects etc.

I wrote an article on it:
http://timothybowler.com/2008/11/20/scrum-in-a-small-agency/

Secondly, we are web dev shop and we work on many projects simultaneously.We are a team of about 10 mix of dev/designers and a PM (Me) and my assistant. Will Scrum work for us?

Thanks
Ervin

Note the emphasis on “Clear definition of Backlog items just needs to stay one step ahead of the team. No further.”

We did scrum for about a year on a project with thousands of backlog items. Our Product Owner devised a huge, complex, politics-management structure for making his priority decisions without offending all of his sources of information.

But none of that is part of Scrum. All we need as developers is clarity when the rubber meets the road. Being more than one step ahead just pushes influence from development out into customer relations, marketing, etc., where we don’t belong.

Let those groups learn what the effects of their actions are in the environment as it is defined. If they don’t like the effects that their manipulations of the Product Owner have, they will learn to interact with him more productively, or he will learn to manipulate them back.

E.g. We often went through long periods of thrash, as the PO was overpowered first by one set of external interests and then another, but THAT WAS NOT OUR PROBLEM: They got the best work possible out of us, far better than when those influences intruded into our lives directly.

The point is, being at the helm of a storm-tossed ship is hard. But we are the SHIP, not the Captain. The Backlog is the wheel, not the chartering service. Scrum runs development, not the business goals.

The PO lives in two worlds, the fact that his other existence is Hell, does not mean that his role as PO for your group should get fire and brimstone all over it.

However, lately I personally came to a conclusion that general commitment to do Scrum and eagerness to Plan-Do-Study-Act is more important. Especially, when it is for historical reasons uneasy to dedicate the whole team to the project.

I think of it as of a retrospective-driven transition. If you got poor feedback loop, the best first steps can move you only a bit in the right direction. If you got good and short feedback loop, retrospectives can quickly correct the wrong steps take. For example, some of my teams at the moment do move from multi-project development to a couple-of-projects development, exactly because it was one of the highest impediments identified by the team. Later I expect them to move further to a single product development. Plus some internal improvements.