Hot answers tagged

71

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


39

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


20

I don't think I have ever used this, but I have generally thought of a Start - Finish dependency as being used where an agree period of handover is required between two activities. Consider the following scenario: In a system implementation project, it would be quite normal for project personnel to provide a level of support for a system for a settling ...


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


17

IMHO the "Super Sticky Notes" by 3M are the best. They may not be the cheapest but they are worth the price. You can find them here: http://solutions.3m.co.uk/wps/portal/3M/en_GB/Post-Its/Post-It/Products/StickyNotes/


12

We have an index card on our board, that permanently sits in the Backlog, labelled "Technical Debt". Any team member can grab a post-it note and write down T.D. they think we are collecting. For example, if they know that a coding decision could have complications later down the line, we stick it on the Technical Debt card. At the beginning of every sprint ...


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

I am wondering what you mean by practical. There is no easy way out of estimating and there is no way of estimating that will yield 100% accuracy 100% of the time (in fact, it'll yield 100% accuracy about 0.00003% of the time). It is an iterative process using ALL available resources and methods that pretty much point to a general area of where you should ...


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

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

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


8

A SF dependency will look exactly like a FS dependency with a lead in units of time if you are looking at the network diagram (notwithstanding the arrows). The difference comes down to the logic of the constraint. For example, the FS dependency with a two day lead is saying that task 2 is scheduled to start two days before task 1 is scheduled to finish. ...


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

Both David and Iain have given good examples. As David said, it's the logic that's driving the dependency. Most tasks are FS - task B can't start until task A is complete, and task dependencies are looked at as straight hand-offs. SF simply inverts the logic - task B can't be considered complete until task A has started (the hand-off has occurred.)


7

I'm currently reading Agile Estimating and Planning by Mike Cohn and he describes a solution to the problem you are having. Sometimes, like in your case, a lot of user stories are just to small and in planning are estimated with 0 story points. In that case, you might want to bundle a number of user stories and bundle them together in one package, so they ...


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

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

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


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


7

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


6

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


6

From you board it isn't obvious how your deployment process look like. Is it possible to deploy the app rapidly, e.g a few time a day? It so it should be possible to move small tasks through the board, and just mercilessly move them to the right edge of the board. However even then it would be sort of pain in the neck as the whole process of moving something ...


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

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


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

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


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