The product owner role

Product owner is a key role in scrum, yet, not much clarity can be gained about it by reading the scrum guide.  This has been deliberately done though. The scrum guide  basically highlights that the main responsibility of product owner is to maximize the value of the product and work done by the development team. It leaves it to the organizations to find ways and means to achieve this. So the organizations will have to work towards establishing processes, ways and means to ensure that the  objective of  product value maximization is achieved.

The key responsibilities of the product owner as per the scrum guide pertain to managing the product backlog. This he  achieves by continuously engaging in activities mentioned below, where required, with the development team:

  • Clearly expressing Product Backlog items
  • Ordering the items in the Product Backlog to best achieve goals and missions
  • Optimizing the value of the work the Development Team performs
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

More product owner responsibilities

The product owner has the authority to cancel a sprint in case it is not adding value. As part of the sprint planning meeting, the product owner should discuss the sprint objective with the development team. During the sprint, the development team can negotiate the scope of the the sprint with the product owner in case it turns out that the work being done in the sprint is not contributing to the sprint goal.

During the sprint review meeting the product owner invites the scrum team and key stakeholders. He also, accepts and rejects the stories done. He also discusses the product backlog’s current status.

The product owner also keeps a watch on the progress made and what remains to be done, at least once every sprint.

The scrum guide clarifies that the product owner is one person and not a committee. This does not mean that there can’t be more than one product owner, but just that, there should be only one, who decides, some call him chief PO.

Mike Cohn adds that Product owner should have a vision for the product, he should be one who understands the market, the customer and business.

The product owner is in the driving seat, he has to spend a lot of time managing stakeholders. He has to be  sufficiently empowered and available to ensure maximization of product value. Non-availability of product owner can seriously hamper work and is detrimental to the project health. Hence it should be recorded as an impediment  for the story and shared with the scrum master.

Agile implementation in Work as team

There are multitude of agile software tools available and each one implements agile in their own way.  In order to understand the implementation in the tool, it would help to go through the sections below on how various features are implemented.


There are three types of backlogs, product backlog, release backlog and sprint backlog. Any new story which is not planned for a particular sprint or release is added to the product backlog. When initially you are identifying various epics and stories without consideration for when you would take them up for development, you would add them to the product backlog.

In case you do release planning, you can move the required set of stories from the product backlog to the release backlog. Stories can be directly added under a release too. Similarly while doing sprint planning, you can move stories from product backlog or release backlog to the sprint backlog. One thing to note here is that a story will appear only in one of the three backlogs mentioned. And though you may have associated a sprint to a release, a story assigned to a sprint backlog would not appear under the release backlog of that sprint.

The backlogs provides the following functionality:

  1. Prioritize stories by drag and drop.
  2. Inline edit of stories
  3. Filter stories based on entered text
  4. Link one or more stories to epic
  5. Delete one or more stories
  6. Select multiple stories and move them to top or bottom of the backlog
  7. Export product, sprint or release backlog to excel.
  8. Assign multiple stories to a team
  9. Assign stories to sprints or releases


Releases and sprints

Releases are optional in the system.  Teams which do release planning can create releases. Sprints can be linked to releases if required. Both releases and sprints can be in any of these states:  To Plan, Planning, Started and Complete. When a release or sprint is created, its default state is To Plan. Releases and sprints in this state are only visible in the Releases and sprints page.  This state can be used to put a timeline of when releases and sprints will start and finish without going into the detail of what stories they will have.

When you are ready for release or sprint planning, the sprint/release status should be Planning. Only those sprints/releases are available for allocation of stories, which are in either Planning or Started state. The application allows running of multiple simultaneous sprints.

Sprint planning

The sprint planning exercise comprises of two parts. First, where you identify the high priority stories that you would like to work on in the sprint. This exercise is done by the product owner. Second, where for each story the tasks required to deliver the story are identified and you estimate the amount of time it would take to accomplish them. This is to get a fair idea of how much can be achieved in the sprint.  The second part is done by the scrum team.  Not all tasks may get identified at this point and a number of tasks get identified when the scrum team actually works on the stories in the sprint.

The first part of the sprint planning exercise is done with the Manage backlogs page. The second part of sprint planning is done in the Task board, where the team can add tasks with estimates for stories. The total amount of estimated time is displayed at the top of the page.

Managing sprint progress

Story board enables team to mark stories as started or completed by dragging them to In progress and Completed lanes. In case you have created tasks and want to track how much work remains to be finished to complete the tasks, there is provision in Task board to enter remaining work.  The summary of how many hours were planned, how many hours have been worked upon and how much more is remaining can be seen in the Task board.

The story board provides provision for raising of an impediment against a story. The impediment can be cleared once it is resolved.

The story which have been completed can be marked as accepted or rejected by the PO. This can be done as and when the stories have satisfied the definition of done.  It is not mandatory to accept or reject stories before marking the sprint as complete.

Story types

There are a well defined set of story types in the application: User Story, Epic, Bug, Chore.  An Epic is a bigger story and cannot be assigned to a sprint. It represents a set of stories. An epic can have an epic under it, but the application does not maintain a hierarchy.  All other story types can be assigned to a sprint.

Story estimation

Currently the application only support story points for estimating stories. Stories without story points cannot be assigned to or added to sprints.

Scope management and Agile

Scope is one of the elements of the triple constraint. Any changes to scope have direct bearing on both cost and schedule, and hence scope has been a top item for project managers to keep an eye on. The top two goals of any project are on time and within budget. Hence managing scope is one of the key responsibilities of project managers. In fact getting grips on scope is one of the earliest things we try to do on a project, even before we land a project in our lap, we need to understand what the project is all about. At the proposal stage itself clarifications are sought on scope. Proposals sent out have sections on in-scope and out-of-scope so that there  is no ambiguity about it. And only based on clear understanding of the project scope do companies make financial bids and work on the project timelines.

In traditional project management, scope has been managed by following processes around defining scope, creating work breakdown structures, verifying scope and monitoring and controlling scope. While each of these processes are required in both traditional and agile projects, the difference lies in how we do these things and how we approach the whole concept of managing scope. In traditional projects we try and find out scope in as much detail as possible upfront, so that we can make better estimates and deliver to predictions.

Whereas in agile, we don’t try to do that, in fact we embrace the reality that requirements cannot be clear initially and only with gradual discovery, delivery and feedback will the product evolve. Just in time and only as much supporting documentation as would be necessary is the mantra for agile. Agile keeps user stories  in product backlog as a form of scope document  to pull next work items from. Stories are used only as a pointer to discuss them in detail when it is time to bake them into working software.

The traditional specification documents are cast in stone months before end users could see software woven to those specifications. This creates issues such as:

1. The feedback cycle being too long. So if there is an adverse feedback, it will impact a larger part of the product, in comparison to where the product is delivered frequently and in smaller chunks.

2. Any changes to the specification requires you to generate a new version of the specification documents and any downstream design and test documents, creating a lot of re-work.

Lets go about discussing how  the scope management knowledge area in traditional project management is addressed in agile.

Defining scope : There is no upfront requirements finding phase in agile as it exists in waterfall. Usually the Product owner along with the scrum team start creating the Product backlog. Clarity emerges on requirements during backlog refinement. Stories are picked up for delivering in the next sprint from the product backlog.

Creating WBS : As there is no focus on creating upfront scope of work for the entire project creating a WBS is not required. Project is only planned iteration by iteration where any need to break larger stories into smaller ones is doing during backlog refinement.

Verifying scope : Verification of scope is done both as part of continuous backlog refinement and further during sprint review meeting with the Product owner where the outcome of the current sprint is demoed to him.

Monitoring and controlling scope : Instead of focusing on controlling scope, agile focuses on delaying requirements discovery till before start of  the iteration in which they will be delivered, thus limiting chances of changes. Any changes to delivered stories will again be added to the product backlog as new stories. Managing scope is one of the key responsibilities of the Product owner.

Inheriting a stressed project

At one point in time or other you would have inherited a troubled project.Either you would have replaced an existing project manager who was shown the door or one who found way to some other company as he already predicted that year’s appraisal. Whatever the case may be it is challenging in itself to take on a project which is already underway for some time. But things get even more difficult when you have to take over a project which is already in distress and you have to do a cleanup.

There can be a number of challenges in such situations that a new project manager may have to face, such as:

1. Relationship with client is strained

2. Project will end in red or is already in red in terms of cost, schedule etc.

3. Team is demotivated & stressed

4. Best team members are leaving others are looking to switch

5. Management is micro managing the project as they have lost trust in the project team

So what should be the approach in such a situation that can turn things for better:

1. Assessment of the current situation

Make an independent assessment of the current situation. You should involve the whole team in this process but still I would recommend that you make you own independent assessment as views of the existing team members may be biased or clouded. An outsider view that you bring will help you get a clearer picture of the situation.

2. Find and analyze factors that have lead to the current situation

There may be many different underlying factors that have contributed to the current situation. Some might be beyond repair if drastic steps are not taken. I would like to share a couple of causes of project stress from projects I was a part of.

i. Team composition: In one of the projects the percentage of newbie programmers to experienced programmers was very high as the senior management wanted to have better gross margins as they had won the project on thin margins. The result was that team productivity was low and hence they could not make deliveries on time.

ii. Aggressive delivery dates imposed by the client: One of the clients did not listen to our arguments on why we would not be able to deliver on the required delivery dates.

One thing to take note though is, that one root cause can create a number of related problems. For example, a team struggling to deliver on time may get stressed, resulting in people leaving, quality worsening, client relationship taking a hit.

3. Share your assessment findings with your own management

It is the management who has brought you on the project, so it is important that you keep them in loop about what you are doing to bring the project on course. This will help you get their support, which is very important in such situations.

Your management is keen to see things improve, but they could be part of the problem in the first place and you should not shy away from highlighting any issues stemming from them. If your management is mature they would accept improvement suggestions regarding such issues.

4. Make a plan to address the situation

The steps that you would take to address the situation should be put as a plan with responsibilities and timelines.

5. Share assessment and the plan with stakeholders

Share the assessment details and the recovery plan that you have made with relevant stakeholders. This will help you win their support to get the plan rolling and help boost their confidence in the efforts to improve project execution.

6. Continuous monitoring of the plan and on-course correction

Understand that plans should be treated as a starting point only and as things unfold, the plans will need to be continuously reviewed and revised.

A coordinated attempt to get things back on track is very important, hence keep everyone in loop on the how things are moving post putting the plan to work. You may not be able to recover on all the affected parameters, but even if you are able to improve the situation on the most important ones, it would still be better.

10 quick things about Agile user stories

A user story is a description of the functionality desired by the user. A collection of related user stories is called a theme. A large user story is called an epic. An epic can span releases. Larger epics can split into epics.

1. User stories exist to facilitate dialogue between team and the users.

2. User stories shift the focus from writing to talking.

3. A story is not a specification as in a requirements document but captures the essence of the dialogue.

4. Collaborate to discover user stories.

5. Use regular backlog refinement meetings to refine user stories further.

6. Keep the story simple and use active voice.

7. Focus on what is important, user story should not be very detailed.

8. Add acceptance criteria to user stories

9. Stories should be equally understood by developers and users.

10. User stories at the top of the product backlog are small and are well understood, whereas those at the bottom are large and lack detailed understanding.

Standard style of writing user story is:

As a …… I want to ……. so that …… .

This format identifies the user role who participates in the story, the feature she wants and the purpose that the story will fulfill. Though it is not necessary  to follow this style.


Causes of Agile project failure

A number of clients want their vendors to use agile on projects, in the hope that the projects would be better off due to various benefits attributed to agile such as ability to handle changes better and faster delivery. However Agile is no guarantee to success if the factors necessary to do healthy agile don’t exist or are weak. Version one, the Agile software solution company’s 9th Annual survey published in 2015 came up with a number of statistics on the state of agile adoption across various companies in North America and Europe. One of the questions tried to find out the leading causes of agile project failures. Lets review their findings (The percentage figures along the causes are the % of respondents who cited it as the reason of failure. Respondents could choose multiple responses.)

1. Lack of experience with agile methods (44%)

Getting used to agile methods takes time. The way agile is, it is a matter of doing it, learning from the mistakes and making adjustments to suite your project needs.  Hence it would be preferable that the team has a good mix of people who are experienced in agile. A team entirely new to agile may find it difficult initially. If that is the case coaching should help.

2. Company culture at odds with core agile philosophy (42%)

Agile many not do well without support from the broader  organizational environment .  So just trying to make the project agile without espousing agile values and principles at organizational level may be detrimental to agile projects.

3. Lack of management support (38%)

This should probably improve with company culture shifting towards agile adoption. But it would require educating the management about agile so that they contribute to agile adoption rather than impede its progress. It would be better to conduct courses for the management where they are educated about how planning and monitoring would change with Agile or else they will make the life of the project difficult team by seeking irrelevant documents and give impractical suggestions.

4. External pressure to follow traditional waterfall processes (37%)

I could not understand which external party is being referred here, but if it is the management, then this point does get covered in point 3. You can make your own sense of this.

5. Lack of support for cultural transition (36%)

Transitioning to a new way of working definitely requires support from within the team, from the management and the client. Without everyone’s active support the transition would become more difficult and may eventually fail. So take the impediments that come on the way in the stride, learn from them and move on.

6. A broader organizational or communications problem (33%)

Communication can be a problem with any kind of methodology and can certainly impact the project outcome. I would not attribute communication as a cause of failure specifically to agile, but of course  agile can succumb to communication problems as well.

7. Unwillingness of team to follow agile (33%)

This could be true for teams which find  their current processes and methodology to be better and moving to agile might seem like creating confusion. There could be a number of other factors too related to some team member’s perception of agile and how it could impact their position of influence etc. Everyone in the team being a team member may seem threatening to some.

 8. Insufficient training (30%) 

A new way of working and especially agile which requires a mindset shift definitely requires training the team and insufficient training can cause difficulties on-boarding to agile. But if coaches are aligned with project teams and retrospectives are effective in fostering continuous improvement impact of insufficient training can be reduced to some extent.

The complete report is interesting can be found at

10 ways Agile differs from traditional project management

Different project execution methodologies practice the same engineering activities of finding out requirements, converting them into design, coding and then testing. But how they go about doing that is what differentiates them from each other. So what differentiates agile from traditional project management. It is basically how the two methodologies view the project. While traditional project management treats a software project as predictive where what is to be done is clearly understood, agile treats a software project as adaptive, where little clarity exists about what is to be done, and it is only with time that clarity would emerge as a result of ongoing collaboration with the product owner and delivery of parts of software. So lets talk about these differences one by one.

  1. Big up front planning vs adaptive planning

Traditional projects create a project plan for the entire project. In agile, the complete project is not planned end-to-end, only those stories are planned for initial iterations which are high value and clearly understood. It is more like just-in-time planning with teams finalizing plans for the iteration they are to doing next.  In traditional methodology big up-front planning gives a lot of comfort both to the management and the client, however short-lived that may be,  due to visibility into future project execution. Whereas agile makes managements and clients who are new to agile somewhat uncomfortable due to lack of clearly laid out project execution plan.

2. Absolute vs relative project sizing

One of the key difference between traditional and agile projects is that the traditional model uses absolute sizing measures such as function points whereas agile follows relative sizing using story points, ideal days etc. Usage of relative sizing renders usage of project size for metrics comparison across projects useless, and hence cannot be used for creating organizational baselines either.  So for agile projects it is not possible to say that the efficiency of one project is less than the other based on  metrics such as Hours/Story points.

3. Collaboration with customer to get to the right product vs delivering as per contract

Agile is more suited to projects with evolving requirements as that is the premise that the approach works with. So there are better chances that you would get to the right product with agile vs using traditional methodologies.

4. Prioritizing and delivering vs delivering in bulk

While whatever needs the project has to fulfill have to be fulfilled whether you do it with agile or traditional ways, agile focuses on delivering the most valuable work first. This is taken care by following a process called backlog grooming where the most valuable stories are bubbled up in priority to be done first. In comparison, traditional methods do not have such focus on prioritizing, individual team may though make such plans.

5. Bare minimum ceremony vs following processes

Agile believes in delivering with bare minimum ceremony. Only as much as is really required would do. Agile teams would rather share the in iteration bugs by directly telling the developers than log them into defect database, if that would work. They would rather do rough sketches of design and convert them directly to code rather than create elaborate design documents. Agile teams prefer using simple means to achieving ends such as use of post-it notes to manage  progress of an iteration.

6. Fewer metrics in agile

Traditional project management has a lot of metrics. Metrics such as Productivity (Hrs/Function point), Defects/FP, Functional  and unit test cases/Function point are maintained among many others. It is believed you cannot improve what you cannot measure. Hours go into crunching these numbers. Auditors review these metrics and are used  to feed the organizational baselines. So there is a full fledged industry around metrics.

Come agile, and lot of it is gone. Teams who move from traditional to agile projects go hunting for the metrics to be followed in agile as they start on new agile projects as many of the traditional project metrics are not relevant. Metrics are used to plan better and improve in traditional projects, whereas in agile, retrospectives and daily standups are used to improve planning and execution. This is not to say that there no metrics used in agile, there are just other ways plan and manage, and some metrics are certainly used as per teams needs.

7. Fixed scope and time vs Fixed time

In traditional projects both time and scope is fixed. Any change in either leads to re-planning. In agile projects the project timeline is chunked into equal time-boxed iterations, so time is fixed. What scope will get done in each iteration is finalized before starting the iteration. In case a certain committed story could not be done in the iteration, the  iteration timelines are not revised and the story is moved to the next iteration.

8. Continuous delivery vs Staged delivery

While traditional methods move in a stage gated manner from one phase, to next phase and eventually delivering the software, agile focuses on delivering working software every iteration.

9. Command and control vs Self organizing team structure

Traditional project management runs using a command and control structure where decisions are taken in a more centralized fashion. In contrast agile lays focus on team based de-centralized decision making where the whole team decides and stands by their commitments. Roles such as scrum master are only meant to coach and remove any impediments hampering progress.

10. Customer participation

Traditional projects usually have high degree of  customer interaction during certain stages  such as requirements gathering and acceptance testing and to a much lesser degree otherwise. In agile however customer interaction is a uniformly spread across project timeline in the form of Product owner’s participation.

Agile may be frustrating initially as you transition from traditional. But with time and right guidance, teams can surely perform at their optimum levels. Both the methodologies are are good for different kinds of project, you just have to make the right choice for your project.

5 questions to kick start your predictive project

If you have been assigned as the Project Manager of your very first project and have decided to use the waterfall methodology, then this article is for you. Here are 5 questions that need to be answered to kick start your project.

So you have been called by your Program manager or Delivery head and informed that you are the Project manager of the new project that the company has just got, congratulations ! You are handed over the documentation, such as the contract document, any earlier communication, project charter, size estimates  etc. You don’t have anybody on the team yet and you really have to start from scratch. Before you can get cracking at the project, you got to answer a few questions which will help you move forward.

1. How big (size) is the project ?

2. How much effort would the project take ?

3. By when is the project to be delivered ?

4. How much effort would go into different phases of the project ?

5. What skills technical or otherwise  are required for doing the project?

Though there would be many more questions to answer, these are some of the most important ones. So lets go about answering these questions one by one.

1. How big (size) is the project ?

Finding the size of the project is important to estimate the effort required to complete the project. There are different measures of project size, such a Function points, KLOC (used usually for migration projects) and others. As you buy potatoes in Kilo grams you measure software size in Function points. There are guidelines on how to measure software size in FP (can be found on the IFPUG site). Usually sizing is done earlier as well during the bidding process and some estimates may exist, but it is recommended that the Project manager does his own size estimation. This will help him own the estimates and highlight the revised estimates to the management if they differ significantly from the earlier estimates.

2. How much effort would the project take ?

Once you get the size estimates, you can get to answering the next question, which is how much effort would the project take to complete. To answer this question you have to derive the amount of effort required based on the size of the project. But project size is not sufficient to answer this question, you need another factor that will help you to the right hand side of the equation. And that factor is productivity. Productivity can be understood as the number of hours it would take the team to deliver 1 Function point. Organizations will have productivity baselines for different technologies, check with your PMO or intranet website to get it for your project technology. Productivity is different for different technologies because it may take less time to do the same functionality in one technology vs the other. So once you have productivity in place finding total project effort is as simple as (Size X Productivity) = Effort. But take note that there may be other factors to be taken into consideration for getting closer to the right effort estimates. So if your project is to support multiple languages, multiple devices etc. Effort estimates have to take them into consideration in addition to what you get from Function point calculations.

3. By when is the project to be delivered ? 

Usually the answer to this question is provided by the client, but if your effort estimates indicate that the timelines are too aggressive, it is better to talk to your management and the client and share your concerns and come to a mutually acceptable set of timelines. It is better to do this as early as possible, no one likes any delays on their projects and it better to share such concerns early.

4. How much effort would go into different phases of the project ?

Different phases of the project need different effort to be completed. Usually requirements phase takes much less effort than construction phase, so you would need fewer team members during requirements phase and would ramp up the team during design and construction. So to help you decide on the number of team members required for each phase your organization should provide you with the baseline phase wise percentage effort distribution for your project type. And once you have these figures you can split the total project effort across various phases. Based on the project schedule and the effort split across phases you can derive the number of resources required across your project timeline.

5. What skills technical or otherwise  are required for doing the project?

Find out what skills and technologies would be required on the project by going through the project documents. Creating a team with the right combination of skills, technologies and experience can be a challenge. So while you are doing other planning activities, start engaging with your resource management team to get the right people for your project. Any delay in getting the right resources on time will have a direct adverse impact on the project.

Setting up a new project is a much more exhaustive process than just answering the  5 questions above, but they will certainly get you started to asking the next set of questions that you need to answer.

Where is your project on Agile manifesto slider

Agile had been in existence for long before Agile manifesto came in year 2001. Penning down of the Agile manifesto was a sign that we now better understood what Agile meant. When I had first read the agile manifesto it did not dawn upon me how profound the four statements where and how just these four statements create a complete mind shift in the approach we take to deliver projects. Moving from a more mechanical way of doing things to a more aware way of doing things, where the focus was not on somehow getting to the other end of the delivery pipeline, but delivering value.

Today when I look at the manifesto, I see it more as a set of sliders. On the the left side of the slider we have ‘Individuals and Interactions’ and on the right we have ‘Processes and tools’. Agile teams would set their sliders to a measure where they think it would best meet the project interests under their particular circumstances.  This would be quite challenging for teams new to agile, vs those who have done it and been there a few times. But having said that every project is different from the other and one would need to still look at fine tuning where the slider is to be set for the project.

I find that it is much easier to go to the extreme right towards the ‘Processes and tools’ side and follow the rule book, though it does not absolve anyone of their responsibilities. Its mechanical and each cog in the wheel knows it role. People might get faulted more for not following a process rather than producing a crappy product. I mean, if you have all the sign-offs and have delivered what the client asked for, your job is done, even if it creates no value. So it is much easier on the team in that sense, though even producing crap can be hard and exhausting.

On the other hand doing agile is more demanding on the teams as agile advocates preference for ‘Individuals and Interactions’ over ‘Processes and tools’ which shifts responsibility equally across the team. Which of course is good for projects, but requires a more capable team. A team which is self motivated, driven, good at communication, at decision making, a team that does not require a command and control structure, and is committed.

Where you would want to set your agile manifesto slider would depend on a number of factors that would influence how much you can adhere to the principles of agile. Some of them are :

1. The kind of team members you can conjure up for the project. Whether they are agile aware, trained, have worked on agile projects and do they have access to an agile coach.

2. Availability of Project owner. Whether he will be able to play his role well or will a Business Analyst proxy for him. How will the arrangement ensure that team has access to clarifications and queries when required. What will be impact of the delays if any.

3. Weather the team is distributed or co-located. Distributed teams face more challenges especially if they are in different time zones.

4. Whether the management understands agile or are they ones who will start demanding a schedule on day one.

5. Whether the client understands what to expect with agile and their share of contribution to the project.

6. Degree of clarity on requirements. If the job at hand is pretty concrete and well understood, such as doing a migration project, from Visual basic, to Java, even lesser degree of agility may be fine.

So if you are onto a new agile project, consider the factors which will influence the position of your sliders on the agile manifesto, and as per true agile values, keep shifting the sliders as the team learns and adapts while delivering great value.

How to create a Gantt Chart using Project Planner

Creating and maintaining a project plan is a key responsibility of the project manager. A new project begins with understanding the scope of the project, creating the Work breakdown structure and creation of a project plan. The project planner is provided to support the project manager in creation and maintenance of project plan. In the following sections we will see how to create and manage a project plan using the project planner tool.

A number of newbies to project management do not know how to go about creating a project plan, basically because they may be using excel earlier and excel is not equipped well for creating project plans. The first thing that one needs to understand is that a plan is based on work breakdown structure and when dates and resources are allocate  to activities elaborated in the work breakdown structure, then it becomes a plan or schedule. Hence the first step to creating a schedule is to create a work breakdown structure. Lets begin then. When you click on the Project Planner link in the menu, a grid such as the one in excel is displayed. The columns of the grid have the headings Tasks, Duration, Start, Finish, Predecessor, Assignee and Work.  So how to do we go about populating the grid to get the plan is the question.

We begin first by creating a work breakdown structure. Here the focus is to ensure that all the activities required to create project deliverables are identified and structured. The grid is blank so you can start to decompose the deliverables into all the activities required to generate those deliverables. You can use the up and down arrow keys to move vertically in the grid and use Tab and Alt+Tab to move across the grid. You can also use the Enter key to move downwards. Using the Enter key on the last row would add a new row. Selecting a row and pressing the Del key would delete the row. A row is said to be selected when the row’s background is light blue in colour. Press Ins key to add a new row between to existing rows.  Two of the most important keys though are Ctrl +  -> and Ctrl + <- . They are used to indent and outdent and provide the ability to create a hierarchical structure required by the work breakdown structure. So with the help of all these keys you can go about creating a work breakdown structure.

The second step post creation of WBS is estimating the duration of each task. Duration can be entered in hours or days only in the form of 5h or 2d. The tool automatically calculates the start and end dates of tasks based on the task duration and predecessor identified. You may define predecessors or duration first, but focus completely only on one activity at a time. So if you decide to define the predecessors first identify the predecessors for all tasks across the plan, and then go to defining the duration of the tasks. In both these cases, you do not need to separately set the task start and end dates.

The third step is identifying the dependencies tasks have. At this point focus only on those dependencies which are there because of the task types, such as a review task can only be done after creation of the work item. You will need to revisit dependencies again when you do resource allocation because, a resource allocated to a task can be only do the next task once he finishes the earlier task. These are dependencies arising from resource allocation.

The final step is allocation of resources, here, you have to solely focus on allocation of resources for the project plan. Currently the tool does not support allocation of multiple resources to a task. To take care of the situation where you are planning in the initial stages of the project and you do not have all the resources available, you can create dummy resources by clicking the on add dummy resources button on the top right side above the grid. These resources can be assigned to the tasks as of now and subsequently, these resources can be replaced in the grid by actual resources.

Creating a Work breakdown structure and subsequently creating a schedule from it may take many days. So every time you work on it don’t forget to click the Save button at the top. And once you are done with creation of project plan and want to publish it to your team click on the Baseline Plan button. This creates version one of the project plan. The resources who have been assigned the tasks would get to see the tasks assigned to them in their Task inbox.

Once the plan is baselined, the project planner view of the plan is displayed as disabled with a Re-plan button at the top. In case it is required to modify the plan subsequently one can click on the Re-plan button. This re-enables the plan and you can either modify or add new tasks, but those tasks which have been started or completed are not permitted to modified or deleted. You may baseline the project as many times as is required. Two links at the top of the page, show the gantt chart view and the resource chart view of the plan. You may also use the filter by asignee function to show tasks assigned to a particular resource.