Hot answers tagged

92

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


51

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


14

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


10

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


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

Estimates are a tool that supports planning. Anyone that needs to make decisions and build plans about the future can use estimates as a tool to make predictions and figure stuff out (without knowing for sure, you can only estimate; but having an estimate - any estimate - is sometimes better than not knowing at all). So for example: upper management can use ...


8

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


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


8

The direct answer to your question is that how you bill your time to the client is not addressed in Scrum. Therefor there is no billing model that is expressly anti-scrum. If adding a place on the board where you track time is the easiest way for your team to keep tabs on it, feel free. Now, there are billing models that can incentivize anti-Scrum behaviors. ...


7

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


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

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

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

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

Creating user stories is to get the conversation going and to give the team context to understand the problem at hand to create the correct solution. Also it forces the writer to think about the value it adds. Using something like INVEST makes sense here. If the value of the technical tasks is clear I think using a user story format is just waste of time. ...


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

Scrum works best if you have good product ownership, fixed-length iterations and a stable team. If the backlog is determined by the client and the team is stable then (barring leave and unexpected absences) I would expect the cost per iteration to be fixed. So if you need to apportion cost per item then the right way is surely to divide the iteration cost (...


7

I'm not convinced that what you describe fits the notion of "large, non-reducible tasks". So far, I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint. Fixing a critical bug that is hard to pin down and resolve The steps here are pretty straightforward: Get reproduction steps. ...


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

TL;DR Respect the time box, and do "just-in-time planning." Don't do so much up-front decomposition, and rely instead on iterative delivery to provide you with an emergent design. Analysis From an agile planning viewpoint, you're doing something fundamentally wrong if your backlog requires complex dependency graphing. In particular, you're either: not ...


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


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