22

According to Mike Cohn It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. Accordingly to Scrum.org: The Scrum Goal is the creation of productive and creative ...


8

Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories: As an SDK user, I would like to be able to grant permissions to a user so that I can manage what different users can do. and As an interface user, I would like to be able to grant permissions ...


8

I am personally adverse to the idea of ever saying a sprint 'failed'. Scrum uses the term 'inspect' 27 times, and 'adapt' 16 times over the course of the guide. Scrum also has no notion of 'failure', and the only reference to failure in Scrum is listed here: Failure to include any of these events results in reduced transparency and is a lost ...


6

Why should a developer want to work Agile? Because a properly-implemented agile framework improves the pacing of a project and the sustainability of the developers' work efforts. It also increases collaboration between developers and stakeholders. If it doesn't do all of these things, then the team (or the organization) is probably Doing Agile Wrong™. ...


5

TL;DR While quality can be measured objectively, defining the domain-specific elements of quality for your organization isn’t something where you can rely on a standard dictionary definition. In fact, most of the issues you’ve identified aren’t intriniscally quality issues at all. They seem more like organizational issues. We’ll look at some of them in ...


5

You can adopt agile with any size of team as it is an approach to doing software development. As you mention in your question, one of the key aspects is to favour responding to change over following a plan. It gets a bit more complicated if you are talking about using agile frameworks. The Scrum Guide suggests a minimum team size of 3. This is because with ...


5

Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically. So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case. Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns ...


5

You're not qualified to second guess your developers. And this is too complex a question to ask on the internet. I'm sure this is a thing that impact your work, but why do you feel you need to come to some decision on technology. Do you have a very junior team? Either 1) Trust your people. 2) Hire some better, more senior, more expensive people who you ...


4

Scrum Master as Coach & Process Referee: Teachable Moments Is it the responsibility of the Scrum master to intervene and interrupt a team member when he/she starts telling about points beyond those 3 that I mentioned? Yes, it is. The Scrum Master is a servant-leader whose primary responsibilities are to act as both a coach and a process referee. The ...


4

Neither Project Manager nor Scrum Master is normally a line-manager function. I don't know who came up with the idea of doing that in the first place, but it seems that mistake has been corrected. So as you are no longer the boss by hierarchy, you need to ask and answer yourself the following question: how does the team profit from my work. How does my work ...


4

Patterns are things that have been observed in the world and found to be good. The idea has their roots in Christopher Alexander's work in architecture and planning, primarily books like The Oregon Experiment and A Pattern Language. They were popularized in the software field by the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) ...


4

In my view, any necessary labor that was exhausted in order to build the finished product or provide a service deliverable would be chargeable to that project as a direct expense. The test would be, would an employee perform the questionable task if it were not for the product being produced? If the answer is no, then it should be a direct expense to the ...


4

From the Scrum Guide: During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. So basically, in each Sprint it's not enough to keep yourself ...


3

I could say something about each of your points, but will address one. If you address this one, then you will figure it all out (eventually). “Software developers started leaving project” Ask why? Ask them why? Ask the people that are remaining why? Hold regular retrospectives, find out why, have the developers find and fix the problems. Give them as much ...


3

Bottomline: go for the approach that'll help you solve the end user needs (features or bugfixes) faster. A task should reflect the issue from end users view. You can do a triage, but I'd avoid rephrasing what the user has complained about. There are three main reasons to stick to user wording: it's a waste of time to rewrite what's already written ...


3

TL;DR Level of effort and complexity are much better metrics for estimating work than lines of code (LOC). Furthermore, they can only be effectively estimated by the people who will be doing the actual work. Using proxy metrics that don't map to actual costs is not a good way to plan a project or forecast a budget. Unless your company is actually paid for ...


3

Before Agile was taught in school, people were doing Agile. There just wasn't a single name for it. The start to what we call Agile was in February 2001, when seventeen people met in Utah to talk about the things that they found were working well in software development in a world where there were a lot of projects that were behind schedule, over budget, ...


3

I don't see that SAFe and traditional agile are really comparable in an apple-to-apple sense. Traditional agile is terrific and when in doubt doubling down on the agile framework is a great idea. But at a fundamental level when you need to have 10 agile teams working in the same direction on what's essentially the same initiative you need a way to ...


3

Experiment. No answer presented here will fit your specific product, team or customer. Agile promotes continuous improvement, so go for it. With that in mind, we can review some key items to consider while experimenting: Why changing? Have clear the problems the team is intended to address by applying these changes. Changing for the sake of change "to ...


3

This is really a question for the team to discuss amongst themselves and decide on what feels right. If you are using the Scrum Framework a good guide is that you have a minimum of enough ready user stories to cover the first sprint. Keep in mind that if you only have one sprints worth of stories that you will likely need to spend a sizeable fraction of ...


3

IT IS! People forget this or gloss over it all the time. Pushing authority down the hierarchy has a lot of benefits for the organization and the individual but it is definitely harder - and for some people, it isn't worth it. For those that find it worth it, some of the most common reasons are: 1) Pride - Along with ownership comes a pride in the work that ...


3

A failed sprint means you did not reach the sprint goal. That can mean all stories but one were completed, but that one was critical to reach the goal. Only you can know whether this is the case here. Keep in mind that the stories pulled into the sprint are a forecast of what the team should be able to do. Saying "all stories must be done" as some ...


2

The same rules apply as for a bigger team: Make sure the stories are well defined Estimate the work as good as possible Have a planning session and plan the sprint according to the capacity Do the work during the sprint You could argue if it makes sense to have all the SCRUM related meetings because there are only two of you and you work very closely ...


2

Agile is very much built around trust and empowerment. Micromanaging and trying to 'catch out' teams is incompatible with this. Some of the effects of the current approach include: By providing top-down technical solutions you take away ownership from the team doing the work. If things go badly, they may just think 'well it wasn't our idea in the first ...


2

What do "as soon as possible" and "tight deadline" mean? As soon as possible, to me, means that this becomes your highest priority and you put in your best efforts to achieve the best schedule duration you can. This could be two days, four months, three years. Tight deadline means, to me, that someone is asking you to target to finish at your most ...


2

Typically my advice in your situation is to reflect the pain. That is to make it clear to everyone concerned the difficulty of the task you have been given to help them have a realistic expectation of when the work will be completed. However, as your manager has told you not to talk about it in front of the client then you are being put in a very difficult ...


2

I feel like I can't voice this as a concern during our stand up meetings because I will be told by my manager that it's an internal issue and that we shouldn't talk about it when our client is there. What "you feel" and "what is" are not necessarily the same thing. You won't know until you do it. If you do not feel stand-up is the right environment, you ...


2

Let's start with the basics: No, that isn't Scrum. In fact, that type of action is expressly forbidden from multiple angles in Scrum. Next, understand the consequences of whatever action you're going to take. Are you ok with this work environment? Are you allowed to request being assigned elsewhere if you are not? Picking a fight on this issue probably won'...


2

The reason is exactly as you guessed. "coming from a certain industry and for them it makes sense." If you look up the definition of the word "business" in say Merriam Webster's online dictionary you will find multiple definitions. The first listed by Webster more closely matches the ideas you think of when you encounter the word, but the second: "ROLE, ...


2

Apart from using two boards, your proposal will certainly work. Having separate boards for bugs and new features is a very good way to ensure that either bugs get ignored or that new features get mis-labeled as bugs to get them implemented. You will find that in the day to day work, at least half the team will only look at one board. If you are unlucky ...


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