How do you manage early phases with scrum (not inolving specific software delivery)

Do you have the opportunity at this early stage to define an agile contract with your client...one whereby product development can be funded incrementally?

Thanks Ian. This is an internal development, it is a product that is going to be built and the commercialized. So, there is no external client. We usually think on needs in the market, we identify them, then create a producto to solve those needs and then we go out and commercialize it.

I would use physical sticky notes and a large wall. I would use nothing more than a title/high level description of each PBI. If it doesn't fit on the card, write less. Then have them prioritize it. Then go into more detail on the top few of those and break them down into manageable chunks.
At this point I would think it is all about setting expectations - That you will show working software at every sprint review and the price of admission is their feedback.
Working agreements would most likely help too - not just for the 'development team' but for the stakeholders as well. Get everyone on the same page and help manage the expectations & level of involvement that is required to be successful.

Your questions were very vague, so I just ran with what you thought. I hope it helps. If not, please be more specific and I will try to help!

Good luck!

> This is an internal development, it is a product
> that is going to be built and the commercialized. 

It's highly advantageous to establish incremental funding for an agile initiative, regardless of whether a customer is external or internal to the parent organization.

If you can frame the budget in such a way, you can effectively limit risk to one sprint. The degree of Product Backlog refinement that you need to start sprinting is consequently minimal.

Thanks Ian and Tim.

After reading your comments, it seems to be that I don't understand very well when do you gather requirements.

So far, what I do with my team is to spent like 2 or 3 weeks talking with the client who requested the product, we try to identify all of the requirements, we try to get as much specific information as possible about each identified requirement, then we document it as deeper as possible and right after that we start with development. So in this first weeks, none of development is done.

Are we doing it in the right way?

... we try to identify all of the requirements...

May I suggest you read the Scrum Guide ?
It explains that "A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful."

Thanks Olivier, you're right, I knew this and did not realize, my bad.

Additional question: so how does this work with budgeting? Is client then by agreeing to incremental budgeting ok with knowing only what it will cost based on individual PBIs? This goes along with the statement above that PBIs evolve and there can be more than originally identified? How can they predict total cost?

At the beginning of the project, we try to make the most accurate estimation and we know that the project cost may vary as we go building functionalities. It usually leads to discussions and arguing with the client about costs and schedule, but so far, I don't really know how to handle it. I just try to negotiate the best I can.

> Is client then by agreeing to incremental
> budgeting ok with knowing only what it will
> cost based on individual PBIs? 

By agreeing to incremental funding a client should be OK with the projected cost/benefit of the end-of-sprint *increment*. That's the smallest level of granularity they can usefully fund. In Scrum that should correlate to a meaningful Sprint Goal.

Trying to work out the cost of individual PBI's isn't useful, because their value can only be realized once the goal is met and the increment is released.

Hi.

First of all congratulations to Fernando for making one step forward to adopt scrum.

I think you have to consider follwing things.

1. A clear buy in from sernior management. They should support this idea. If they do not then it will be a difficult jopurney but not impossbile.
2. Change in mind set of Team as well client is required.
3. You also need to build team whose foundation if based on Trust and Courage rather than Fear.
3. You need to allow team to fail. I will ask ... is your team allowed to fail for next few sprints? Can your business afford that?
4. You may also want to read Scrum Guide .. Not just read it but read may be 3 - 5 times and read each line carefully.
5. Do not make decision for team but allow team to manage it .. In this process they may fail but eventually team will learn.
6. As this is internal project, easier way will be to ask for a budget for 6 sprints or 1 years with a fix team. So that you do not need to bother about budget.
7. Have a good product owner and scrum Master. Look in to Scrum guide .. Scrum Master is not a project manager.
8. Organize training for client as well as team.
9. Have you heard EPIC, Feature and user stories....? May be explore that and try to organize your stories under one Epic then further down..
10. Team will decide what it can pickup ..not client or a manager. You have to give them chance. Thats why I said let them fail. important thing is what tehy can learn from retrospective....
11. May be you know that valley of a change .. it will be like a shape of a cup.... You may expect a dive in productivity but after few sprint..it should improve. Search for change curve.
12. Get ready with architect need not to be fully defined but an overview of what needs to be done should help you. Later on based on requirement , architect can evolve.
13. If possible start with colocated team not more then 9 team members. ( 1 product Owner, 1 Scrum Master, Max 7 team members - developer, BA , tester etc).
14. Use physical board for putting your product backlog. If you do not have any then may be you want to start with excel but not recommended at all... so it is a temporary solution meanwhile arrange for a physical wall where you can put your sticky.
15. Look for automation tools which can be used.
16 do not expect that Scrum wil be adopte din 2 - 3 months ... Depending on organizarion it may take long.. but it can be done in less then 3 months as well but I do not know backgound of your company.
17. Most important start with a very easy story .... but follow scrum as much as your team can..... laster on pickup complex stories....
18 Last but not least.... Transparent, Inspect and Adapt. Even if team is not following all rules as mentioned in scrum guide allow it but if you do a good retrospective then eventually it will improve every sprint....

I think I will stop here.

If you have doubt or question(s) feel free to ask it...

Wish you and your team success !!!

Cheers :)

Thanks a lot Mahaveer, this is really a good answer, I really appreciate it and of course it is really really helpfull.

As you could see, I had to wait a few weeks to continue with the post. It seems to be that in my company, we will continue using waterfall with some agile practices. The practices are just the meetings. I don't know how it will work, but well, it is what I have.

However, I'm still very interested in learn how to implement scrum in the right way. And about it, I'm wondering this:

- Every time I answer how to proceed when a requirement is changed everybody tells me that I don't have a good DoD. It might be right, but, isn't it supposed that scrum is appropriate for a changing requirements environment?

I've discovered yesterday the Agile Inception concept as the work to do before the first sprint. It looks pretty much good and was helpfull in order to understand how to start with scrum. There is also a book called the "The Agile Samurai: How Agile Masters Deliver Great Software, by: Jonathan Rasmusson", I haven't bought it yet, but it seems to be oriented to this discussion.