Scrum Project manager

sai0824 used Ask the Experts™
I have read in Agile scrum is that you have a 1) product owner 2) scrum master and team.

1)As a Project manager where do you fit in here.
2)Is product owner the sponsor or customer?

Will there be no initiation phase in agile. LIke we have project charter, prelimenary scope statement and we have Rough order of mangitude defined.

Dont we have all these in Agile. What about planning Phase? Is it the same in scrum.

Not clear about these though. Please let me know in detail.

Thanks in advanc.e
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Kevin CrossChief Technology Officer
Most Valuable Expert 2011


Disclaimer: I am neither a Certified Scrum Master nor a Certified Project Management Professional, but I have made Agile and Scrum combination work successful in a small manufacturing environment. The advice below is my interpretations and practices there and is not to be taken as the letter of the law for Agile. I recommend looking into the work of Martin Fowler, Kent Beck, et al.

First, take a look at the as it answers some of the questions.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The traditional need for extensive project plans and design work up front is not necessary if the customer or user is involved in the design. You will find that the documentation evolves over time via collaboration and so isn't totally lost—just deemphasized. The critical point is that instead of fighting scope creep, plan for the change in the requirements which is the root cause.

The way I use Agile and Scrum:
Product Owner => Sponsor
Scrum Master => Project Manager
Team => Developers, Customer, etc.

You are reading that right. I put a nontechnical business user on the team and make them design the screens and collaborate with the developer. Had a project that was about a year or so stale that I took over project management on and ran through Agile with Scrum process. It was up and running within weeks. The product gained velocity as business users "actual" started using the tool and as such uncovering bugs and clarifications in business need became very easy. So I can attest to the benefit of getting a working product in front of the user versus trying to get all usage details upfront. The reality is that there often is a disconnect between how users actually use a product versus what the process is. Finding some of the subtle use cases takes time. Consequently, there have been several enhancement releases since and business customer is extremely happy. That should be the goal. Time to value is important. It is tough as a project manager, so you will find that most in Agile still combine it with other project management techniques – just don't let them hinder the progress of the collaboration.

Scope can be tracked via Product Backlog. I hold an initial meeting to get rough overview—"big picture"—as you want to design with some idea of ultimate goal to ensure flexibility in architecture. For specific feature or portions of the project, you have Sprint Logs that has details on stories or tasks within a sprint. As Sprints complete, if there is release associated, I have a demo. Following the demo, I required user test for week at which time there was a scheduled planning meeting for the next Sprint which is simply confirming which tasks to include. This is where you can move items around in the Product Backlog, i.e., handle change in requirements or priorities. During each Sprint, you have daily meetings. For us, we went with every other day. My reasoning is that we are a small organization with limited resources and so we need time to actually get work done. But treat as a daily meeting and ensure to answer "what happened yesterday," "what is scheduled for today," and "what are the road blocks, if any." These questions help the project manager—scrum master—keep things on track. Your project sponsor—product owner—helps move road blocks, keeping your team moving forward.

For the Sprint and Product Logs, I used some simple spreadsheet templates I found, but as you have this tied to the Microsoft Development area you may find this helpful:

Hope that makes sense. If not, please ask. I had a lot of thoughts in mind when I started to write and not sure it all came out clearly or if I stayed on track to answering all your questions. If I did, great. If not, as I said, please feel free to ask for clarification plus others should opine shortly.

Respectfully yours,


Hi Kevin,
Thanks for sharing your experience.
Few doubts

1)  I read that no one assigns work to the scrum team. they themselves do it.  Scrum master (ie Project Manager) is not involved. How does this work out? how can they take this responsibility and how is that they manage distributing work. really not sure about this.

2) Without SRS (Software requirement specification) or Functional spec how can the team understand what needs to be done. Normally during SDLC design phase Tech Lead creates a HLD (High level  design document) and later LLD (Low level ) which contains pseudo code to the programmers. Without all these how can the team know the exact requirements to be developed, considering the team have a mix of experienced and fresher candidates. In normal model we also design use cases, but I dont see in Agile we follow these at all. Direct execution looks like.

3)  What about Earned value calcuations for Project Progress tracking . Dont we use Microsoft Project in AGILE?  


One more question.

I was asked by guy "In agile model lets say during a first sprint cycle I am supposed to deliver the pie of work within next 2 days". But due to some problem we could foresee that testing would take 4 more days . Now should I  release that work or Ask the customer to buy more time" if agile methodology is followed. Depending upon this situation, what could be the answer.
According to Agile rules for release what has to be negotiated with the customer?
Chief Technology Officer
Most Valuable Expert 2011

Depends on who your customer is of course and what it is you are working on. One reading of Agile is to deliver on-time no matter what. So if the product can run on its own, then you would release in two days good, bad, or ugly. For me, I build in time for testing by the team/customer. So plan for testing before diving into next Sprint. This allows the team to ensure they are heading on the right path. If there is no consequence or accountability to releasing when you say, then that might be a recipe for failure. However, on the flip side, do not become a slave to deadlines and missing the point. The goal is to get value to business or customer in the shortest period of time. If you are having major issues, that should be brought up in daily/periodic scrum meeting and that is where the Scrum Master (Project Manager) and Project Sponsor come in handy.

1) Yes. Using the Product Backlog, the customer defines the requirements (stories) and the developers define the level of effort. Between the two/team, features and tasks are prioritized and worked on Sprint-by-Sprint to releases that make sense to the team. The project management is needed to ensure that dates are met and road blocks are cleared. Don't think of the project manager role as a dictator of tasks, but a facilitator and the mechanism to keep folks accountable to the team. i.e., having periodic scrum updates is the responsibility of the project manager IMHO and is moreover their task to ensure that meeting stays on tract. It took me a while, but you have to keep meetings to 15 minutes and keep even the product owner who may be a CEO to not talk design details. Team members should be doing that throughout the process, right?

2) Think Product Backlog. Further, think Sprint Log and story boards. Your prototypes and wire frames are the documentation on what needs to be done. COMMUNICATION is key. This is about the customer and the developer working hand-in-hand, so having a team member who knows the business side sitting with the developer who knows the technical side is wonderful. But as I said, you can do this however fits your organization. You will find some organizations still use Waterfall or other project management in conjunction with Agile/Scrum. You may manage the project as the stories, sprints, and products; however, within a sprint a more experienced developer may write specific tasks out as pseudo code or strict design for junior developers to follow. There is nothing stopping you from having design patterns or standards, just do not let them cripple your flexibility or the benefits of doing Agile in the first place. Being Agile doesn't mean being unorganized or undisciplined. Quite the contrary. You will find that code documentation and standardization is more important. Code is likely better thought out also if you are truly programming with the thought that requirements will change, i.e., you code knowing you will snap in other structure later versus coding everything just for the exact specification which is likely incomplete or even WRONG. Customers may not know technology at all and it may be a few iterations in before you realize that they did not mean what they said.

3) You have hours, tasks, sprints, and product/release. You can still tell a burn down of work that should be left in the project as well as what was actually done already. I am in a smaller organization and so don't really have to bill back after each sprint, so can't comment to much on this piece. My customers are internal. What I can tell you is I can track it sufficiently...



Hi Kevin,
Sorry about the delay. Thanks for that. It was very informative.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial