Skip to main content

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

Last post 09:01 am January 30, 2015 by Fernando Moyano
13 replies
02:14 pm November 14, 2014

I have to start managing a project from the scratch, and, I want to manage with scrum the early phases of the project, which involves meeting with the client and the users in order to understand their needs.

My thought is that after this "early stage", we should have the firts version of the product backlog.

So, my questions are:

* do you write user stories to manage this phases?
* how do you build a backlog to this stage where we're gattering requirements?

I think this also applies to manage non-software projects with scrum.


02:18 am November 15, 2014

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?


07:30 am November 17, 2014

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.


11:51 am November 17, 2014

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!


01:36 pm November 17, 2014

> 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.


07:02 am November 18, 2014

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?


08:27 am November 18, 2014


... 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."


09:22 am November 19, 2014

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


03:28 am November 23, 2014

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?


08:59 am November 25, 2014

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.


10:02 am November 25, 2014

> 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.


05:03 am November 26, 2014

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 :)



10:43 am December 9, 2014

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?


09:01 am January 30, 2015

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.