10

You can have a technical leader. You can have him do work off the charts. You can hide this work from others that don't "need to know". You can reduce that person's capacity to make planning more accurate. But you cannot call that Scrum. One of the key features of agile (and, by extension, Scrum) is transparency. Transparency: This means presenting the ...


10

TL;DR If the work matters, make it visible. If it doesn't, then treat it as muda and trim it as non-essential waste. You truly cannot have it both ways. No Invisible Work, Ever!™️ CodeGnome's Law of Transparency says "No invisible work, ever!" Any work that is off the books violates that law, as well as generally-accepted agile principles and practices. ...


7

If you assume an employee puts in 8h days, this rule would mean that a task takes no longer than two man-weeks and no less than one man-day. This ensures that the task is large enough to be meaningful, but not so long as to have no visibility into what is happening. In other words, a task that takes 4h may not be worth doing--it could be wrapped up with ...


7

What you are trying to visualise is a network plan, not a WBS. A WBS does not show dependencies, only the scope or deliverables and subdeliverables that needs to be realised in order to succesfully complete the project. A network plan places all WBS-elements in their logical sequence in order to show the growing maturity of the project deliverable. So ...


6

TL;DR Communication plans or communication activities should only be included in a work breakdown structure if they are the deliverables. Even in such cases, the breakdown should reflect steps in the project rather than daily calendar items of interest only to the task performer. Define Your Level of Granularity Your question is not directly answerable ...


5

There are two types of communications, in my view. One as a consequence of doing work, the other as specific outputs or deliverables. For the former, I would not exhibit it in the WBS because it does not buy you anything from a measurable point of view. I would consider this type of communication--risks, meetings, troubleshooting, design discussions--in ...


5

No, the WBS is not outdated, obsolete, deprecated, nor useless. The WBS is just a decomposition of WHAT you want to deliver. Building a WBS is not a one-shot task, but it is an interactive and iterative process. One best practice in project management is to create a product oriented WBS, that you will use later to structure your planning. In my article "...


4

In Effective Work Breakdown Structures, Haugan has "Project Management Elements" as a toplevel WBS item and moves all such work under that element. A lot of people don't consider process documentation to be an output of a project -- but it is. Such documents form inputs to other projects and to analysis. They're clearly a tangible output, and so belong in a ...


3

There is nothing in the agile approach that specifies the size of requirements. Scrum, which is an agile framework, does specify that the amount of work planned for a sprint should be completable within the sprint. That would imply a maximum size of a requirement such that it does not exceed a sprint (typically 1-4 weeks). In practice though, there has been ...


3

It sounds like you might be describing the differences between a Product Backlog and a Sprint Backlog and perhaps a Release Backlog in the middle. Product Backlog- Everything desired in the product. This can be a finite list (a PRD) or a living list that is constantly being added to and re-prioritized. Release Backlog- This is not in the base scrum ...


3

The 8-80 rule was created to help 24/7 health care facilities avoid overtime pay because of scheduling difficulties related to union labor contracts giving the regular staff at least every other weekend off. Because of the weekend off requirements, it was mathematically impossible to adhere to the previous 8-40 rule without a mish mash of overtime payment ...


3

Yes. The WBS should include all the work needed to successfully complete the project. The 100% rule states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important ...


3

Why are you attempting to produce a Gantt chart? I suggest that you read the Scrum Guide as this will provide a background into relevant Scrum artifacts. I expect the real reason is that the business is not buying into Scrum and is expecting artifacts based on project management methodologies such as Prince or PMP in which case you have 3 options... ...


2

I haven't used any of them for PM recruitment but there are a lot of 'collaborative consumption' sites out there where you can post an opportunity and get bids in for the work from suppliers (Elance is one of the most popular). You'll more than likely get bids from individuals or small companies rather than large consultancies. Stepping back a little I'm ...


2

More information is needed to determine if granularity is about right. I'll suggest some criteria that can be applied: Are there any external dependencies internal to any of the tasks? If so, obviously, the task needs to be split to allow the dependency to be tracked. Is there significant adverse risk associated with any of the tasks? If so, can the task ...


2

Given that some communication activities will create dependencies and extend the overall project schedule I think it's essential that the communication overhead is taken into account in the WBS. However, for the most part I wouldn't say that all of it needs to be explicitly included. One of your example activities is the meeting to discuss project risks. If ...


2

I agree with @Daniel's comment that this is a poor question to ask. In terms of suggestions be wary that this may be in part a trick question as a mistake may be components missing from the WBS. For example, a best practice is to include project management activities (initiating, planning, controlling/monitoring, closing) in the WBS as they represent work ...


2

With regards to the level of detail on your project, I'd say you may be going one step further but overlooking one a basic one: What are we trying to achieve with any task management system? Most of the time, the reason one would use a task structure is to make workable more pieces manageable and traceable. As Cornelius Fichtner reminds on his PrepCast, ...


2

"WBS must contain 100% of the work"...that means we must consider all pieces works to be done under the scope of a particular project. WBS elements are defined in terms of "outcomes or results"...not every action/detail required to produce that result (minute detail would part of SRS and Low level Design etc document). How to determine the level of breakdown ...


2

If you can export the data from Freemind to Excel with two separate columns some quick manipulation in Excel to translate the WBS codes into Outline Level, should allow you to import the Excel file into Project and have the task list created with the appropriate outline level. This is what I am guessing you have from Freemind in Excel A1 = WBS The WBS ...


2

Agile requirements process is a conversation Let me try to answer your question in the context of Scrum, which is the most popular Agile process. Yes, you should have user stories in the form of small, vertical slices of functionality, describing a small increment in value to the user. However, reading your question, it looks like the following ...


2

Implementation of a custom ERP is a complex procedure. One should have experience to do it right. As I understand, you are a member of the development team and there is a customer enterprise. If this is correct, you will need: a roll-out engineer in the camp of development who knows how to extract information from an expert and teach the staff to use the ...


2

The complexity of your product the project is creating dictates how the complexity of your WBS. Can you imagine what the WBS of a fighter aircraft looks like? However, one person would not be responsible for building the entire WBS; it would be created by SMEs of the very components being built that create the aircraft when all put together. Your OP ...


2

I've some considerations about this question. I would try not to explicitly define in the Story the complete list of pages, one by one. Guess the pages are forty, instead of four. So my approach would be something more generic As a Sales, I want to analyse the customer behaviour on the [X] pages So that I can sell more ads to specific customers Obviusoly ...


2

I agree that the by strict definition of a WBS and its use lends itself to best be used in the waterfall methodologies...however like mentioned above some of its principles can be applied to managing the Scrum or Agile backlog concept. In Agile . you are essentially breaking the work down into Epics, Features, user stories...which closely matches Project, ...


2

From the Scrum Guide: Scrum is a framework for developing, delivering, and sustaining complex products. Everything in Scrum is centered around the development, delivery, and maintenance of complex products. In this particular case, the keyword there is "product". Everything in Scrum is also centered around three roles - Product Owner, Scrum Master, ...


2

In the context of the rest of the section, it is saying that you should focus on the outcome desired, not the action needed to get there. For example, I might say that I should have infrastructure deployed and sub-items may include networking, servers, power, etc. This is as opposed to the actions needed to get there (configure switch, wire racks, install OS,...


2

The Scrum Guide does not say that a backlog item has to be in the form of a user story. You may write the backlog item the way you like, or more precisely the way the team prefers it to be.


2

Backlog should contain all workable items According to Scrum Guide: Product Backlog is the single source of work undertaken by the Scrum Team. So in my opinion the Backlog should contain all workable items including but not limited to: user stories from all your stakeholders this is business functionality risk mitigation items eg. when we need to do ...


2

I think there is a frame mismatch here, and I don't think the question can be authoritatively answered unless the frames are clarified. My discussion below is very explicitly not to challenge or argue with OP. The way you manage projects is the way you manage projects and should be judged only on how effectively that permits you to close projects. That ...


Only top voted, non community-wiki answers of a minimum length are eligible