Hot answers tagged

57

There's a difference between meeting the deadline and fulfilling all requirements. Its like the old adage "fast, good or cheap, pick two". So here you have fixed dates for delivery - that's good, it means you are time-boxed in that what you deliver at the end of your last sprint will be the final product. You remember that you always have to release ...


35

No. This is the exact sort of things that non-software companies tend to do. There are plans, and deadlines, and budgets. And it will inevitably fail, since humans suck at predicting the future. Let's go through the various points here: We keep being told we are going to be working in an agile way on a new project by senior management. If you were ...


22

If you have fixed scope, and a fixed deadline, then the only thing you have left to play with is cost. You can throw more people at the problem (which doesn't really work), you can buy premade software, or you can sacrifice quality. ...Or you can change peoples' minds about the fixed scope or fixed deadline thing. That's not an agile problem, that's a ...


16

If there's an expectation that specific sets of features are to be delivered on specific dates, then no, this is not agile project management. Agile project management is empirical in nature. Projections are not made based on the wishes of executives but rather on analysis of prior performance. Your description matches up with what I consider to be cargo-...


8

Welcome to real business. There is an older style of business, which I tend to derisively call "traditional development" and then there's a new style, "agile development." If I try to treat these as opposing ideals, we see a straightforward division down the middle: plans and requirements go on the traditional column, discovery and evolution go in the ...


7

What I think you lack here is a product owner. Somebody who knows about the product you guys are working on and who can make sure that the user stories that end up in your backlog meet DoR (Definition of Ready). This, of course, does not mean that the team should take what is in the backlog at face value. They do need to challenge it and ask for ...


5

There's a couple of potential solutions: Is it really the case that the team should be generating ideas? Engineering teams are generally responsible for implementing ideas that come from product management, not coming up with the product itself and then creating it. Perhaps you need a PM to design the product so that the team can stay focused on creating ...


4

EVERY business relevant project has constraints: Time Resources An expected minimum feature set This is nothing else. Developing agile doesn't mean "people pay us money, so we can develop whatever we want for whenever it may be ready" - you will always have some time-frame. There will always be some date with some minimum requirements and if they are not ...


4

Agile does not prevent you from planning milestones (E.g we will release V 1.0 in 3 months), but what goes into each milestones cannot be fixed. I think how you should react depends on the nature of the project. If the project is to send a man to the moon by Q2 2017 everyone would agree that it is doomed to fail. If you think you can deliver an MVP by the ...


3

As someone has already pointed out before the manifesto says: Individuals and interactions over process I would suggest you have a look at the plan put forward and suggest changes to it. Remember the Manifesto says that the backlog is never final, it keeps evolving. So you could take your suggestions to the team. If you have a valid reasoning and ...


3

I don't think that there's a 1-1 mapping between functional requirements and user stories or acceptance criteria. First, your example of a functional requirement isn't a good requirement. It's not atomic - I would write your functional requirement as multiple requirements: The system shall require an email address to create an account. The system ...


2

Yes, an agile approach could help you get the work done1. At its core, scrum provides a way for a group of motivated individuals working together to deliver a product. Scrum provides a framework for breaking a larger body of work into smaller pieces (epics, stories, tasks) and then working on those smaller pieces. Scrum also provides a framework for the ...


2

Time, budget and scope Every project, whatever life cycle approach it uses, has to cope with the triple constraint of cost, time and scope. In your case time and scope are fixed. You say nothing about cost, but as you've inherited this project from your partner, I fear that there might be a fixed (or at least capped) cost as well. The unexepcetd risks ...


2

If someone is going to change a method which is reused somewhere in your codebase, he should be responsible for making an impact analysis before. So a dev who starts to implement a change in DoSomething should check beforehand from where this method is called. So lets assume you already found out DoThisSomethingAndMore won't work any more correctly when ...


2

If you have resources that depend on each other, with resources being [people | work items | code], then they would all be in the same Team Project. You can easily have separate Teams (Backlogs, Work, & People), Git Repositories (code) all within a single Team Project. If you are using TFVC then use folders. Check out https://nkdagility.com/creating-...


2

Imagine asking someone to paint a wall, a house and then a whole street for you, how much time would you give that person to do it ? Whatever your answer is, you'll be wrong. That's it. There's no way they could be right about dates if they didn't ask the people who need to do the work what they think. By the way, if you (as a team) accept these dates, ...


1

Starve them. Seems whacky but what's killing them is you keep spoon feeding them. Scrum works best when you don't push. The more you manage them the worse this will get. If you have a team of smart driven people all you have to do is lay out a goal and make it clear that they are expected to find work. Just make it obvious that you're watching who's ...


1

Functional requirements require people to be able to think abstractly about the problem. Specifications written this way tend to be very dense and have many implications. Often people writing these get confused between requirements and implementation. User stories don't require as much abstraction. They also force the person writing them to think about ...


1

Here's how we roll: The PBI: is the requirement aka "the what" is what you talk about with a customer. It's what shows up on the Daily Project Update (DPU) for the sprint..... again because the DPU is customer facing. It's what the customer will talk about and refer in terms of estimates and budget. Might comprise one or more tasks. Is business oriented ...



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