24

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


13

I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...


12

TL;DR Part of any project management framework, but especially agile frameworks like Scrum, is the necessity of continuously managing stakeholder expectations. People want what they want when they want it, but a big part of project management is explaining to people what they can actually have within the various constraints impacting the project. As the ...


11

Let me challenge the frame of your question a bit: Why do you have such specific requirements that change for every ticket? Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...


9

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


5

Another prioritization schema you can use is to score each feature using over value--benefit and penalty--and cost and risk. The picture below is a sample of what this would look like: Each criterion is scored 1 through 9, 1 being low and 9 being high. Benefit criterion is obvious; this is how the feature would add overall value to the system, ...


5

Agile thrives on collaboration between people, rather than building walls around each team and throwing things over it. The ideal situation would be that the designers work in the same team as the developers and create their designs as the software is being developed, with the technology used to deploy the designs. This way, the designer is the one who ...


5

The three main reasons why a late project ends up later if more people are added to it are - as pointed out in the Wikipedia page: The new people need to learn, so they take time away from the existing people in the team for help. So less resources to do the work while the new people become productive and actually start contributing something. ...


4

Practically everything you've said is a cause for concern but the project should be salvageable. I suggest you concentrate on two things. Firstly, as Mark also suggested, it seems from your description that you don't have clear ownership of the project. Someone will need to set priorities and be accountable for costs and that isn't your job as PM. If it's a ...


4

One possibility would be using a tool like Slack. Create a team news channel. Anyone who hears any relevant news or notes any significant comments/events during the day will add them as a message on the channel. People returning to work after having been away can scroll back through the news.


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


4

Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today. One of the reasons we work in iterations is because it gives us ...


4

I think DevOps defines the best practices here: specifically the principle of small batch sizes. In other words, if the batch sizes (code commits) are small, then the code reviews can be frequent and short. I would live with the frequency because that's more of an Agile thing and it's OK! Build a team culture that supports it. DevOps also tells us to ...


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


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

I initially didn't want to answer this question since the comments do a proper job of capturing the gist of it (i.e. discuss it with your SM/colleagues), but since I don't like neither of the currently existing answers, I'm just going to throw a wrench into the works here. One of the answers basically says "How does the Scrum Master dare to do this", while ...


4

[...] you have 10 options, but only time and budget to realize only a pair of them You hit the nail on the head with this: "time and budget". You need some technique that accounts for these two factors. The SWOT analysis doesn't really account for either. You may do your analysis but then how do you chose? Do you go for the highest opportunities? The lowest ...


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


3

It depends. It's important to realize that Kanban doesn't have anything to say about code reviews. It's simply a set of tools for visualizing and improving the workflow and flow of work through a workflow. There are a few key concepts - the Kanban board which provides a visualization of the workflow, work on the board, work-in-progress (WIP) limits, work ...


3

I suspect there is no single answer to this question. Individuals are different. Some may find that doing a code review is a welcome distraction from their coding tasks. Others may struggle with the context switching or may not enjoy doing reviews. Teams are also different. I can see the nature of code reviews varying depending on many factors including: ...


3

I've experienced similar issues with literally every team I've worked with. I've learned that the problem is not the lack of a great tool to solve it. Daily standup meetings are pretty common and useful if executed correctly. The most common problem I've seen in dailies is that everyone is rushing to express himself/herself and make sure that he/she has ...


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


3

If you are making large scale changes to your underlying infrastructure code then The Mikado Method might be useful. Methods and Tools did a review on it. There is a book on it Mikado Method for Legacy Code by Ola Ellnestam & Daniel Brolund Another book Working Effectively with Legacy Code by Michael Feathers is also a useful resource.


3

TL;DR There's no right or wrong answer here in terms of what activities, columns, and swimlanes belong on a given Kanban. However, it's likely that your process is being driven by a software tool choice rather than reflecting the actual workflows and working agreements in your process. You should carefully evaluate whether you have captured the right ...


3

Are you producing a deployable increment of product each sprint? If so then agreed delivery dates are already being met and that is the best way to minimise risk and give the customer confidence in what you are doing. The stakeholders (via the product owner) should get to decide which things they want and when, so what's most important is that they continue ...


3

TL;DR Successful leaders measure project outcomes rather than individual productivity. Measuring individual productivity is generally an anti-pattern that obfuscates deeper structural problems. Do you have too many bugs? Turn your teams loose on reducing the amount of bugs released into production. Are bugs taking too long to fix? Get your developers and ...


3

Beyond the four values, these principles are also relevant: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. and Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. and Working software is the primary measure of progress. ...


3

Do you have to deliver working software in an Agile timebox/sprint? If you are building a software product using sprints, then yes, you should deliver working software each sprint. The point of a sprint is to have a cadence of activities and an inspection point where you look at what you've built, collect feedback, adjust your understanding based on the ...


3

As mentioned by others already - sprints are part of Scrum. They have nothing to do with Agile. It used to be that Scrum Guide stated the ideas clearly, but the further we go the more obscure it becomes*. Current Scrum Guide says we have to deliver an increment by the end of the sprint, and the increment relates to "value". It seems that the ...


2

It is possible for you to break jobs down into multiple levels of subtasks if you use the Hierarchical Task analysis method. Hierarchical Task Analysis is a detailed examination of the tasks users must do to achieve particular aims. This document explains how to carry out task analysis: http://www.idemployee.id.tue.nl/g.w.m.rauterberg/lecturenotes/UFTtask-...


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