Tag Info

New answers tagged

2

If you're doing it right, the development load towards the end of the sprint should be lighter. If it's not working, development are flat out fixing bugs and trying to get stories closed. Some options are: Preparation for the next sprint. I like the team to have a good idea about what is likely to be in the next sprint and be thinking about the stories ...


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


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


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


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


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


-1

Deadlines are not agile, they are: 1)Waterfall, and 2)Wrong. Software and deadlines do not work well together and never have. In many ways, the Agile methods are a reaction to the massive problem of missed deadlines or software which was abandoned when it became clear that the deadline could not be met (as well as budget issues, too). Agile attempts to ...


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


0

The purpose of software development methods, when understood correctly, is to make us more productive by focusing our thoughts, and to provide a common language for typical situations. It's about inspiration and enabling, not about mind control and guilt. Following a software development method literally with no compromises whatsoever corresponds to what is ...


0

The degree of agility required in one's work is inversely proportional to how high their position is on the organization chart. "Agile" is good, for what it is. "Agile" sorta means "open-minded coupled with sufficient competence." It's the grunts at the bottom that have to be the most agile. If, at management levels, the pointy-haired boss was agile ...


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


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


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


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


82

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


1

I've done my share of pair programming and training rookies. First of all, it really depends on actual talent. Some developers will never grasp abstract thinking and are most happy developing basic features or executing basic programming tasks. Others will want to dive into the full code base of the applications you're building and contribute to ...


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

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


0

There are many reasons: Mindset: Many of the developers working on mainframes do their work for decades. They 'grew up' with water fall and aren't exposed that much to new ideas as other environments where the average developer has maybe 5years experience and brings lots of new ideas to the table. The environment: A lot of stuff they code is tightly bound ...


1

I would suppose there are two factors which lead to this: Mainframes are used for applications for which Waterfall is usually more suited: Many mainframe applications are business-critical or life-critical: those projects require a lot of paperwork and don't fit well with Agile. You rarely see mainframes in start-ups. Mainframes are rather used by ...


0

Also user story pointing gives the business a heads up in terms of if anything needs re-negotiating. if you have a month to complete some work you scored as 100 then you might be in trouble. it also gives you chance to break an epic story down into something smaller that still has value and can be completed in a sprint.


0

Ok. i think we've got a solution with the user stories. I can understand how to break them down further now so that they still have value to the business. Part of our problem is tackling too much work at once. This means we have very little velocity for a few sprints and then it jumps massively when everyones work is complete. Our approach is to move ...


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


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


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


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


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


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


1

There are several testing-related questions: Which parts to test? Units (unit testing), whole system (functional), several systems together (integration) Which aspects to test? Functionality, performance, reliability, security, etc. When to do testing? Before (TDD/BDD) or after (non-TDD/BDD). Or never =) How deep to test? Or, how to view the system under ...


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


1

What you have sounds like what is known as an Epic. This is basically a user story that is too large to be implemented, tested and accepted in a single sprint. This should typically be the starting point to go back to the customer and try to derive more details and specifics around what they want. You should be doing this as a regular part of your backlog ...


1

A user story is actually some text of your customer. You should split that story into valuable backlogs. If it's hard for you to write them, because they take too much time to be reasonable valued you have to consider a story split. That means you talk to your stakeholder and recompose the user story in more smaller user stories. The thing is, that scrum is ...


0

Lots of good answers here. Hopefully I can add some value with another one... I think one hang up your team might be having is migrating from a non-Agile methodology. That's usually some form waterfall methodology and, in practice, that usually does involve trying to document all technical requirements before a line of code is written. But that doesn't ...


0

TL;DR User stories are for documenting what value should be added to the product, and why. Implementation details (e.g. how the value should be added, tested, measured, or validated) are constrained by the story, but are not contained within them. They are deliberately left as separate artifacts to maintain flexibility and agility within the framework. The ...


1

Make your own decisions The answer to 'So how actually can developers ever develop a story if there are no lower requirements?' is very simple - the detailed requirements that are orthogonal to the needs of the end user (e.g. DB constraints, fields validation, etc) don't actually matter to the user. If the user needs can be met by very different fields ...


1

I think the purpose of this approach is not to constrain user stories, but to prevent bad requirements. In my experience, users are generally incapable of writing requirements. Developers are generally incapable of writing requirements. Heck, let's just admit it straight out: requirements are hard to write! I think it would be valid for a user to write ...


1

I'd say that something like a tree structure works best. You have a few huge 'root' tasks, detailed into smaller but still large tasks, split into small, less-than-a-day, easy-to-track 'leaf' tasks. What you discuss for sprint intake is leaf tasks. But you can always trace them back to a bigger picture, which helps understand which small tasks are more ...


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


1

I think if what your Scrum consultants are telling you is that Scrum doesn't require requirements then you have some very poor consultants. They are even wrong to tell you that a user story is not in fact a requirement at all, they just happen to be one kind of requirement. What are the different types of software requirements? Business Requirements ...


1

A User Story is one specific kind of artefact with the goal of describing the interface that the user expects from the system and that is why low-level details simply does not belong there. If you put them there, you are changing the intent of the artefact and it no longer fits the definition of a US. Use other forms of specification to capture lower level ...


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


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


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


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


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


0

Who are the viewers of the screen? Aren't they the ones who "want" to view the information? About the question "Can a system be its own actor?" Perhaps a system can be its own actor. If you view a system as an intelligent goal driven agent that is proactive towards its own goals and acting based on its beliefs, desires, obligations, and intentions (see, ...


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


1

You may already know about this but you want to look at the books/ movements "Lean Startup" by Eric Ries and "Running Lean by Ash Maurya. Both cover concepts and methods of determining with incremental design, prototyping and development, discovering who your customers might be, what your product needs to be and where it needs to go, and in general, ...


0

Often Agile seems geared towards B2B interactions, where your "customer" is another company with a few representatives who are there to tell your group what they want. From what I understand, you are talking about the situation where you are making a product for mass distribution. In such cases, your customers are millions of people you hope want to use ...


0

I would say you should put yourself in the shoes of your customers. Try to do a SWOT analysis to figure out why would you buy such a software and decide on the potential requirements that a customer would request. From there you can I would recommend reading Business Model Generation written by Alex Osterwalder. I think this is a question that relates more ...



Top 50 recent answers are included