Hot answers tagged

77

A few things stand out to me. The idea that management has that the team commits to a set of work is inconsistent with the latest versions of the Scrum Guide. The word "commit" or "commitment" is only used twice in the most recent (November 2017) version of the Scrum Guide - once when listing the Scrum Values and once to indicate that "people personally ...


50

If you work in a company that doesn't place any value in paying down technical debt, you may have no choice but to do unticketed work. Stakeholders are generally not qualified to make decisions about this kind of work. Include unticketed work as part of your ticket estimation process.


33

The situation that you describe, where management requires that the team works overtime to complete all planned stories, is one of the reasons why the Scrum literature has stopped using the term "commitment." A true commitment can only be given when all uncertainty is taken out, including uncertainty about 3rd-party dependencies, how much work each item is, ...


27

In a few safety-critical industries, you need approval for every bit of code that goes into a product. Most people are not in that situation, and those that are, accept that condition. In normal situations, if you don't allow for unticketed work, you are basically wasting the experience of your engineers, especially senior engineers. They know about things ...


23

Why you shouldn't do it from a team perspective The most important rules of project management regarding teams are: The project can be a success only through intense teamwork. Empowered teams that trust each other are the most effective. One for all and all for one What you are trying to do, is very different. It was called "Divide et impera" by ...


21

Your PM has no business being involved in your scrum. Your PM has no business asking you for unpaid overtime. The obvious thing to do is to estimate all tasks in such a way that you can guarantee they will be finished in time. Then you should be able to go to the pub in the second way, since clearly if underestimating a task means you finish it for free, ...


12

It sounds like you are at the extreme thresholds of Scrum. According to the Scrum Guide, a Development Team that has fewer than three members has less interaction or doesn't need as much interaction as a slightly larger team. Therefore, you may not see benefits from using the Scrum framework in a way that slightly larger teams would. It also sounds like the ...


12

There are a number of aspects to this, but at a high level, yes - the PM will absolutely want to clearly understand why the planned work has not been completed. However, this should be brought up (and resolved) in the retrospective. From the dev side, there are many factors that can contribute to sprint failures. Some things you may want to consider: Too ...


10

No, this isn't a recognized form of Agile, for one very important reason: if you're committing to deliver everything, you're not doing Agile, you're doing Waterfall - and if you think you're doing Agile instead, you're probably doing Waterfall poorly, at that. I'm sure you've heard the old saw "good, fast, cheap, pick any two," right? With software ...


10

I would suggest not making these "continuous ongoing tasks". Rather than have generic "update documentation and review code for bad practices", define very specific work or tasks with clear objectives. Identify types of documentation that needs to be improved or specific problems with specific portions of the codebase. This will let you prioritize the ...


10

You are not Apple or Microsoft. The reason why a software developer at Apple doesn't know about all of Apple's code is that there is a bloody awful huge amount of code and nobody can know about all of it. And there isn't one guy at Apple in charge of their repository. They have more than one :-) What you are thinking about is just totally misguided. If ...


10

should all work no matter how small be ticketed and go through sprint planning rather than be done as and when by developers if it is small? There's certainly a point where the answer is no, right? It doesn't make sense to add a ticket to open the IDE, or to format the code before checking it in, or to code review other's code. One could argue that those ...


8

Yes, a bug should be added to the backlog and tracked just like any other story. I don't think they should follow any special rules though. a business value of 0 If a bug is important enough to be fixed, then it has non-zero business value. no complexity evaluation If you don't estimate the effort required to fix bugs, then you can't plan your ...


7

I see two possible options. First, don't break down the item. In this case, the work item (the story, ticket, whatever) represents the minimum valuable delivery of the work and can be estimated by the team and worked on. The team may break this out into subtasks (either in a tool or informally) and work on it, but the work is tracked at the level and is ...


7

The biggest problem I see with this is that you're looking at a mini-waterfall rather than a sprint. The description you're giving above forces the team to deliver all or nothing. What if they have 12 items in the sprint and deliver 9? Does that mean you won't test or release what has been done? If so then I dread your release schedule, every time any team ...


7

The ticket should be in the column it belongs in, which sounds pretty stupid to say and is exactly why I'm mentioning it. The ticket was being developed, then handed off to QA who found some defects. The ticket now goes back to an engineer to be fixed. Thus, the ticket should go back into development. Each column has a group of people or teams that are ...


7

You don't convert story points into money. The cost of a software development effort is a function of the team for a period of time, perhaps considering resources if you forward those costs along. However, story points do not convert to time, so you cannot use them as an input into cost. Story points are also highly volatile, so even if you tried to convert ...


7

I'm curious why you bother to do estimations at all if you don't have a way to eventually boil it down to approximate actual time. The only reason I can think of is to be able to say "that's too big" and break it down further. Anyway, the most common way to convert your estimates is to measure your actual performance over the last several months. If you ...


6

He is correct, that there should not be any carry-over between sprints. Scrum teams having a carry-over between sprints is an anti-pattern and not something that canonical Scrum accepts as valid result. But, his approach is not a good one. During a sprint, team should constantly monitor work being done and if they can keep their commitment of sprint ...


6

Since I don't have previous experience, I don't know how right/wrong my idea is and I would like your advice: am I on the right track? If you don't have experience, and you are in the role of scrum master or project manager for a scrum team, the best thing you can do is step back and let the team make these decisions for itself. Your job as scrum master is ...


6

The ultimate goal with any estimation approach is to be able to translate the estimates into 'real' terms. Otherwise, what would be the point? What use do t-shirt size estimates have if you can't translate them into real timelines? The reason that relative estimation techniques are used is that people are absolutely terrible at estimating in absolute ...


6

Lets differentiate a bit, you can have many types of unticketed work Doing something completely unrelated to project, eg. helping someone on another team, admin, management meeting Implied by specified work. eg. no-one mentioned security, but we are just adding the default rather than pestering for specs Gold plating. eg. of course you want animations on ...


5

The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide. It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one ...


5

The Book Answer: The Scrum Guide says that the scrum team has all skills necessary to deliver a potentially-shippable increment of the product. This is specifically put into place to avoid situations like you are describing. This is a classic case of "this is why Scrum says not to do this." There are two ways to solve this problem and be within the scrum ...


5

Improving the standup What my question is, how to make this more as a team sync and less as a team rapport? I don't think there is enough detail in your question to answer that. You've described symptoms (some people feeling like they aren't being heard) but haven't explained the root cause. Are some team members joking around without listening? Are they ...


5

Is this an acceptable/common variation of Scrum I am not aware of? No. It's completely wrong. I could maybe sympathize with paid overtime, if the PO made the mistake of giving out the estimates as facts before the sprint end, but unpaid overtime is completely ridiculous and would make me look for another job ASAP. How do you suggest that I should act ...


5

The two approaches are very compatible. In fact, it is completely possible to use both. That said, as you adopt Scrum, there will probably be two significant differences. 1) Scrum is very team focused. That is not to say that you don't have experts on a Scrum Team, but the whole team is responsible to work together and that means a lot less of "my work" and ...


5

You seem to have already answered your own question: Scenario: - There are two external user types - sellers and buyers. From this, I infer that you have other roles that are considered internal (e.g. exhibition host, application admin, ...). You inherently listed buyer/seller as "the external user types", because that is what separates them from the ...


5

Building an application piece by piece using Agile Development means you do not build what you do not need, but you still need to design the architecture for the application. When I see a code base become a patchwork of enhancements with little technical direction I see a number of issues that should be addressed: A lack of technical leadership on the team ...


4

Within Scrum (and to my knowledge within SAFe as well) there is no such thing as a partially completed feature. All features are either on the backlog, being worked on or completely done. And the team only earns credit for features that are completely done. This means that if a feature isn't completed by the end of an iteration, then it should move back to ...


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