Hot answers tagged

83

In Scrum here is the rough breakdown: Epic - something so big it probably won't fit into a sprint, is not clearly understood in terms of customer requirements and should be broken down into stories. T-shirt sizing is a common way to size epics. Another way is to say we think it could take X to Y iterations to do this work. Epics are usually defined during ...


53

If at all possible, they don't. They ask developers to estimate it. Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks: The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done The people who do the ...


46

Epic An epic is like a super-story. When a story is too big to fit comfortably in a sprint and/or contains a lot of unknowns then it is usually better suited to be an epic. Epics are fine on the product backlog, but as they approach the top of the backlog they are typically decomposed down in to several stories. We don't bring epics in to sprints. Story A ...


19

Coordination/Collaboration, Not Formal Task-Tracking While the Scrum Guide used to refer to the stand-up as a commitment meeting, it currently says: The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The purpose of the daily Scrum is not to hold people accountable ...


12

In general there are no rules but what you make. Your Product Owner would define what this means to them, then document and share it. If you look as some of the scaling frameworks available there is a generally accepted hierarchy: A Task is about the how and noone other than the team should be concerned with them A Story is a what that can fit in a single ...


11

Have Task Performers Provide Estimates In agile frameworks (and even in sensible non-agile frameworks), project managers should never estimate work items themselves. Instead, the people who will actually do the work ("task performers") do the estimation! To get the most realistic estimates, have the task performers estimate the time and complexity of the ...


10

The answer is really simple and really complex: Simple Answer: In Scrum you don't Complex Answers: If you know the extra tasks before the sprint starts and the team decides that it's necessary to do them, then just do them and lower the forecast. Common courtesy suggests that you tell the PO why you included the extra task. If you know the extra tasks ...


9

TL;DR Your problem is not actually with granularity or "task bloat." Your core issues appear related to exceeding the team's work-in-progress capacity, and allowing the team to ignore the agreed-upon definition of done. Integrating Documentation with Tasks Network engineering is not like programming. While collecting router configurations could ...


9

When you have dedicated testers it can appear to make sense to have a seperate testing task for them. But when you think about it, testing is really a team activity. For example, a tester may need to speak to a BA or Product Owner to understand more about what they are testing. They may also need to speak with the developers to understand the new ...


9

I will assume that the "push" approach is not only direct, but also immediate. (Like when someone comes up to you and says "hey, Joe, can we roll this later today?"). The "pull", on the other hand, is not only indirect, providing the queue as the go-between, but also delayed. Tasks might accumulate in the queue, waiting to be picked during the day, or ...


8

TL;DR Even when the change is apparently minor, it can have ramifications. The "one-minute fix" to some CSS class might impact the user interface (UI) on some other page the developer isn't thinking about, or might break important regression tests. This is the very definition of cowboy coding. More importantly, bypassing the agreed-upon workflow is a ...


8

Tracking the daily commitments each team member sounds like micro-management at its best. The exception would be for a very short project, or for a tiger-team trying to solve an emergency. When you track daily commitments, either the larger chunks are being ignored (woe to the project) or else they are being unnecessarily broken down into meaningless ...


8

It is very rare that this is possible. But it can happen, so let's look at it: Any estimate is based off of statistical evidence from past experiences doing similar work. If the work we are doing is remarkably similar and we have a large set of data to work from, we can make estimates largely from categorizing the task. For example, I used to work in a data ...


7

On the occasions this has happened with my teams, we look for the smallest testable slices we can make, even if we know we wouldn't release them. For example, we were integrating with a 3rd party and wanted to do single sign on between them and our site. Our story was: In order purchase products on the 3rd party site As a registered customer I want to log ...


7

I think that a FS dependency is useful when you have an activity that can't finish before the dependent starts. Imagine: a watchman is hired to take care of a building during nights and the manager tells him that his activity can't finish until the building administrator comes in the morning. The arriving time can vary every day but the watchman cannot ...


7

I personally wouldn't include non-product related tasks like setting up a new PC in the sprint. Rather I'd identify the team member needed to do the 3 hours of setup and reduce their amount of availability in the coming sprint. Just like you would if a team member has a vacation or is only available x% of her/his time in the sprint. Any amount of ...


7

TL;DR Within Scrum, or any sane project management process, there should never be "invisible work." All work that impacts the project's budget, scope, or schedule should be visible to both the team and the organization. In essence, you are getting hung up on the idea that backlog items or user stories should add value to the product (in your case, a ...


7

Look for ways to deliver limited business value initially ...even if it is not something that you can actually use. Taking your example, if you are going to accept Visa, MasterCard and PayPal, you can first implement PayPal (or whichever is easiest to implement) and then have separate stories to add Visa and Mastercard. If you are going to accept ...


7

Use INVEST for Story Definition and Sizing You are struggling with decomposing your work because your stories don't follow the INVEST mnemonic. In particular, the tasks you've listed aren't testable. How could you possibly tell if you've successfully completed "[f]ind and fix broken JavaScript in catalog files", or estimate the amount of work involved? ...


7

Stuff like that should be in the working agreement of the team. There is no right answer on how to handle the situation but there are pros/cons of creating the story/defect and/or underlying task. Pros: Creates visibility for the rest of the team Leaves an artifact that the work was done Cons: Administrative overhead associated with creating/managing the ...


7

Stories should always be defined in business terms. Why does there need to be web integration? Who is it for? What exactly does it need to accomplish? If it is not directly-related to a business requirement (unlikely for web integration, but theoretically possible), then it should instead be a developer task, and thus it should be defined by a developer. ...


7

I am assigned to an Epic expected to take 3 developers for 6 weeks. There are so very many things wrong with that statement, from a Scrum perspective. I'll go through them in order. I am assigned to Scrum works better as a pull-model, not as a push-model. No one assigns work to developers. In the Planning Meeting, the Scrum Team accepts work from the ...


6

Personal preference, but for me, I only group them by like kind (summary to summary, detail to detail). Summary tasks are seen as separate work packages, ie: they summarize all of the tasks necessary to complete that particular part of the project. So if I link a Summary task to anything, it will be to another summary task (work package). This also helps ...


6

Great question, and I believe in keeping this as simple as possible without adding too many "rules" to what constitutes a task. A PO creates a requirement that needs to be done, this requirement requires work to be done in order to the job done. This work comes in the form of grooming analysis, coding, testing, documenting, deployment packaging, UI design ...


6

The first answer is exactly what you would expect on a PM site and is wrong, for the very reason it gives as being right: "In essence, you are getting hung up on the idea that backlog items or user stories should add value to the product (in your case, a software product), and that anything that isn't part of the software product is therefore an externality."...


6

Epics – Large projects that entail many people over a long time. Stories – Smaller projects within an Epic that must be completed before the Epic can be considered ‘Done’. Tasks – The day-to-day things you must do to complete a Story. Tasks are individual work items that can be done with relatively little effort, like making phone calls, writing an email ...


6

From the process point of view there is nothing wrong with it, because this is the closest thing you have for tracking. However, it may harm the team members on the personal level, and can easily lead to micro management. They may feel an unnecessary pressure on themselves in order to keep the commitments, even if it is not possible to finish the task in a ...


6

TL;DR You should not be defining tasks for technical people. Instead, you should describe a value proposition and some testable acceptance criteria, and then turn your technical experts loose to find a solution that delivers the defined value you're looking for. User Stories Describe Value User stories are a good vehicle for defining value. Using the ...


6

There is a not a single answer to this questions. Its imperative to understand how a team should perform so that you can spot dysfunction and respond appropriately. You need to understand the dysfunction to address the problem. One resource that comes to mind is the book "the 5 dysfunctions of a team". While what you mention initially sounds like "...


5

More than probably your task is set by default as "Fixed Units" so the initial 22 hours of work are not kept fixed. Now 217.13 days * 8 hours/day = 1737 hours (the task duration in hours) Whenever you add a new resource in "Resource names" column MS Project tries to guess what you want to do. And by default he believes you are adding a new resource with ...


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