Tag Info

Hot answers tagged

88

Deadlines are a reality. Most times you have to have something by a certain date. It's unavoidable. Without deadlines, even agile projects can succumb to Parkinson's Law: Work expands so as to fill the time available for its completion. In other words, if your project can go on forever, it will. In relation to deadlines, Agile tries to do a few ...


26

This answer will focus on how to work with User Stories and lower level requirements. I won't be discussing the virtues, or lack thereof, of Scrum or Agile. I won't be talking about gurus either. This answer assumes you're on board with Scrum but haven't yet found a way to make it work for you. As others have mentioned, User Stories are meant to cover ...


15

Some deadlines must be met. Contractual obligations, conventions, regulatory requirements. Some are imposed by managers who want to be able to put software development in the same chart as manufacturing on their spread sheet. What ever the cause, most people can't get away from them. If you are working in a functioning team then communication between the ...


13

Consider the Project Manager's point of view By asking for complexity they want a number that they can compare with your next sprint to find your velocity as a team. They may also be trying to use it to add together your result with other teams to provide an over all estimate on when all the stories will be done. The project manager's is looking for an ...


10

Deadlines are a fact of life. There are things that have a very firm date. We need the software by Comdex or The games must be on store shelves by Black Friday and the like. One cannot postpone Comdex or Black Friday - the rest of the world doesn't work that way. The goal that Agile has is that things that won't meet the deadline fail faster ...


9

Acceptance tests act at a very different level than, say, unit tests. A unit test is very precise: it deals with one method, sometimes a part of a method. This makes it a perfect choice for regression testing. You make a change. A test fails while it passed during the previous commit. Great, you can easily pinpoint the source of the regression both in time ...


9

I think Frank's and Encaita's answers pretty much covers it but there are some additional things to consider: Why use story points The aim of estimating with story points is to give the relative complexity of developing features for your application. A simple way to think about it is take a story you have in the upcoming sprint e.g. a url change. You know ...


8

Arbitrary deadlines that have no consequences if missed aren't very agile, but there are situations where for reasons outside of the development team's control deadlines must be set and kept. Fortunately, if the deadlines are reasonable there are plenty of ways to invert the equation and handle deadlines in an Agile way. Deadlines aren't always wrong. As we ...


7

Wikipedia explains planning poker quite well. Let me recap some of what's state there with a focus on your case: Why planning poker? First of all, you should all be on board as to why you are doing a planning poker as opposed to a "normal" estimation. The reason is actually quite simple: all of us suck big time when it comes to estimating time for a task. ...


7

Your approach of splitting stories into tasks and moving those tasks across the board is very standard fare in Scrum. There should be no need to report on the task-level in TFS, because tasks don't create value to the business. It is the completed stories that create value to the business. If a story isn't fully completed by the end of a sprint, then that ...


6

Smaller tasks are more easily estimated and implemented. Smaller tasks also make it easier to identify when you're "done" with the particular task. The ideal Agile process is highly iterative, so having lots of short but incomplete lists of small tasks makes it easier to iterate through and develop the proof of concept that you're looking for. Likewise, ...


5

You need someone to be a proxy for the customer. Someone in the team who takes on the role of Product Owner, or whatever it is called in your methodology of choice, and puts themselves in the position of a potential customer. Note that this is a difficult job! But choosing the right thing to build is one of the difficult problems any start-up must face!


5

As pointed out by Bart van Ingen Schenau: The Kanban development method might work well for you. Kanban is a fairly "minimal" method; in particular, it prescribes much less than Scrum. The basic principles are: Visualize the workflow - typically by having (physical or virtual) cards for each task, that move across a board with different phases/steps ...


5

In an ideal world we wouldn't have deadlines and just deliver things when they are ready. The reality though is that people paying for things usually want to know when they are done. Agile methodologies do recognise this but also recognise that not everything can be tied down. So if someone wants to set a deadline then that is fine and the deadline can be ...


4

The system can display certain elements on a screen, means that an actor can "Check those elements on the screen". Try not to describe your system from the point of view of the "system", but from the "Users" point of view: what can they do with the system? I believe an example would help: Let's say I want to talk about an ATM as a system. The use cases the ...


4

Deadlines are traditionally based upon the business lifecycle. Tax software needs to be in by April 15th. Reporting for the next fiscal year might need to be done by July. The Agile manifesto states: Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract ...


3

You may ask yourself why is it impossible to make a release until your changes are done. In Agile projects, it is not uncommon to release several times per day, and still, some features may take days, weeks or months to be done. The usual approach is to have switches that enable or disable the pre-release feature during runtime, so that you, a developer, ...


3

The fundamental problem here is that it is broken. The PM wants to use planning poker to get an idea of the complexity of each story, with the intention of knowing roughly how many stories can be fitted into a sprint (the team's velocity). As a result, its a "not based on time" that is "based on time". Its no wonder everyone gets confused. There are ways ...


3

... who will the future client be? If you can't answer that, you probably have more significant problems than "how to run agile" since you are adopting a, "if we make something cool, people will buy it!" perspective. You can do a variety of techniques to create an identity for this client. Perhaps a user persona acted out by your team members. Having a ...


3

Just don't call this a User Story and everyone will be happy. I think the answer is, you can write this down wherever you want. In general, specific implementations are not included in a user story for a few reasons: You know what the customer wants, but you don't know how it is going to be implemented. The customer is aware there are more specific ...


3

Think of deadlines as commitment. The fact that the project is agile doesn't mean you shouldn't commit to deliver given features for a given date. What agility brings is what happens in between. Instead of having a strict software requirements specification document which defines that you should deliver feature A composed of sub-features B, C, D and E for a ...


2

Yup, its BS. And Scrum is not Agile. I hate the rigidity of so-called agile practitioners who tel you that there is one way of doing agile and that you must follow all the rules laid out in the holy scriptures of whichever 'agile' methodology they use. Its all BS. Agile is about being agile. Agile is about getting stuff done with a minimum of overhead. ...


2

After dozens of iterations in my team, we figured out that story points are mostly about medium-term project steering. They allow the product owner to project herself 2 or 3 sprints ahead and essentially make business and scope decisions about a release, based on an average velocity. We've discovered that story points aren't so much useful at a sprint ...


2

Which is Scrum standard/better in terms of your experience? Getting user stories well defined. If necessary, that means getting the product owner in your sprint planning to answer questions. That will lead to two sort of scenarios: You get your questions answered. Sweet, now you can make your small well-defined stories as you normally would. Nobody ...


2

BDD actually started at the class level. JBehave was originally intended to be a replacement for JUnit. The only meaningful difference between JBehave and JUnit back in 2004 was the removal of the word "test", and the use of "should" to drive out different aspects of behaviour of the class and encourage questioning of those aspects of behaviour ("should ...


2

Despite the "science" in "computer science" and the "engineering" in "software engineering" evoking the idea of having rules, guidelines, and some "correct" method, my experience is you need to trust your gut. Software engineering tells us that the process of paired programming works: your gut feeling tells you how to apply it. This is a human issue, not a ...


2

I was in a similar position once where I was bringing several developers up to speed. The most important thing that we did were constant code reviews, meaning that every commit was reviewed and commented on by everyone. After about one or two months they were not only picking up good practices but also felt confident with the codebase. Also you could try ...


2

I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes ...


2

TL;DR Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development. Many answers here are likely to focus on the engineering aspects of the question. Instead, I will address this from a project management perspective. A deadline implies a great deal of up-front planning which is not in line with agile principles. ...


2

Developers and QA should both work up until the end of the sprint. Developers can spend the last day/few hours working on QA feedback, performing their own unit tests, reviewing or refactoring code, etc. assuming there is not enough time to pull in any stories from the backlog. QA will of course spend the last time in the sprint testing, with any feedback ...



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