Tag Info

Hot answers tagged

11

If you keep it as one single user story and you only get 4/5 filters done at the end of your sprint, then your single story is incomplete. If you split it, then if you get 4/5 filters complete, then 4 out of 5 stories can be marked as finished. When I get stories like this, that have n features of a similar nature (such as your 5 filters, or some ...


8

The title question, where innovation refers to smaller-scale creative advancements in a team that is already doing well in Agile. The best answer is summarized in this article about "Gold Card Days". Summary (paraphrased, and with my own interpretations which may not reflect the author's intentions): Developers can identify interesting (intellectually ...


7

If you don't test a User Story (US) and verify that the acceptance criteria are met this story is not done. If its not done this US goes to the next sprint of course. And if all your US are in this state you sprint has ended with no value added to the project. From the client point of view I cannot distinguish this from the entire development team going on ...


6

Back to Agile Manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Nothing in these values forbid innovation. Actually, innovation has a better nest with Agile than with Waterfall. Nevertheless, it ...


6

I don't think it does. Agile is about eating chocolate elephants - taking a large task and breaking it down into manageable chunks that can not only be delivered, but are delivered regularly. Research type projects do not fit into this - not unless your project can be broken down into small chunks that can be demonstrated every fortnight (or longer - ...


5

One possibility: If you are concerned about loss of productivity by rotating a team member, your manager has the correct approach, and will most likely be seriously concerned (if he's any good), but not saying so. As companies grow, they become less concerned about immediate productivity and more concerned about continuity and predictability. Issues such ...


5

Let me try and address your question as it relates to agile and Scrum (for more details review the Scrum Guide and the Agile Manifesto): In Scrum stories are for the entire team not for individuals. During sprint planning the team and the product owner decide which stories would be tackled during the sprint. In Scrum there is no team lead. A Scrum team is ...


4

I think that there is a common misconception as to what BDD means, that BDD means that we are now writing our tests using tools like Cucumber, SpecFlow, etc instead of traditional unit tests. That is not the case. BDD is more a way of thinking that moves our focus in the tests from the technical aspects to the more business oriented aspects. Also see this ...


4

When I was being indoctrinated to UML (which is a different methodology but I still like this lesson) the premise of a Use Case was: "Someone comes to the system, does something of business value, and then goes away." That provided a nice boundary between use cases, because it divvied the work up into a number of more or less complete process flows. Start ...


4

"New developer leaves the company - wow we wasted a whole bunch of time." There are a classical response to this: why if you don't invest time in the training of this developer and he decides to stay at the company? In my opinion is a good idea that developers rotate between teams, normally this gives developers a better understanding of the company as a ...


3

If the user of your software is not able to update to the new version and use it without further manual migration steps (data, configuration, interfaces and the like), that is a strong indicator to increase the major version.


3

I think some of the challenge starts with your assertion of: Where a Major version is implemented whenever there are breaking changes And I'm pretty sure you mean "breaking changes" in the sense of significant API changes; client / server communication changes; protocol work, etc. "Big Stuff" (TM) in other words. But the problem is that it's not ...


3

When discussing the question above with practitioners from the scaledagile.com, the following questions were raised: Are we achieving the business results with our existing processes? Is the business satisfied with our time to market? Do we have the time, resources and skills to document the emerging process? If we don’t document the new processes, how ...


3

The essential problem is that you have programmers who code but don't test and testers who test but not code. Solve that problem and you will not have this problem, and an arguably more efficient team. One way that worked for me in the past was to suggest coders and testers to pair on stories with the explicit task of delivering a fully tested story. ...


3

if all or most of the coding is not done until the end of the sprint? Why is it not finishing sooner? This key limitation is the source of your troubles, and I've seen two approaches be successful. One fits well into the agile approach (but not other common practices) and the other taints agile a bit (but is more common). The first is that you don't ...


3

The actual role of your QA is close to acceptance testing. I would imagine this to be done by a separate team, which acts more as product owner rather than a part of the development team. Example: during a sprint, you need to add a feature which enables to filter search results by different criteria. You already have your search mechanism implemented, but ...


3

Although agile is based on a minimum viable product and only delivering what you need, it is also based on making the best decisions you can with the information you currently have. This means not only considering the user story you are working on, but what you know is coming, or likely to come. The correct time for design is whenever you need it - ...


3

Part of this is expected and good, part of this is not, and we can't really tell you which is which. The main focus of agile is delivering what is important now, based on what you know today. Take a little bit of time, implement this important bit and ship it so that you can get feedback on it sooner rather than later. Some of that feedback will be "ugh, ...


3

New developer will bring down the work rate of at least one experienced person as they constantly ask questions. This is a good thing, in moderation. Every process has countless sources of friction - be it tooling-related, design-related, or whatever. Trouble is, a lot of your sources of friction you don't notice. Having someone come on board brings a ...


2

Yes, The Definition of Done is created by the Scrum team. The Acceptance Criteria is created by the Product Owner. They are orthogonal concepts, but both need to be satisfied to finish a story.


1

Whatever you're using internally, externally you're still going to have a waterfall like release cycle. Whether it's now called a "feature release", "release to production", "customer delivery version", or whatever, it's going to be the combined product of a number of sprints and shorter internal cycles. That's where the high level numbers come in. So ...


1

Most of the time, people in companies will have an official title and then wear many hats. So the your mileage with any given title will vary, especially if a business's goals are changing, like if they're moving from a product to service oriented business. With that in mind, I'll describe how those titles usually start out. A programmer analyst typically ...


1

Why should this be all negative? New people bring new ideas and insights to the group: New tools Other ways of working By having to explain the ways of your team to them, people in your team get challenged: Why did we decide to do it like this? Is the reason above still valid? Explaining stuff to people get people out of their confort zone And the ...


1

does rotating out the team members work? Define "work". Rotating team members sometimes spreads (good or bad) culture to the different sprint teams. Sometimes it can build teamwork between teams because people get to build friendships that didn't exist before. Does it spread domain knowledge? slowly. Like months slowly. Does it slow down sprint ...


1

In the agile setup I am working with,It is what the team wants.The definition of team here does not include managers and business folks.I agree this may not be possible if you are working in a place where business people have a more say at technical issues. In our case if the team feels that some feature needs a design discussion, we do come up with design ...


1

Something seem wrong: It sounds like the tester (you) is not a part of the team but is a sort of outside assistent, reporting on errors. If you think recording all errors helps quality, why stop at bugs that you find as a tester? Why no record bugs that the compiler finds? Why not record unmatched parenthesis or uninitalized variables, which the compiler ...


1

Thanks for listing my book in your top 5. "Agile Project Management for Government" takes a fresh approach in that I describe real life, fully attributed agile successes. These are case studies at Enterprise scale. I do not favor DSDM (although the book starts with a DSDM case on a breakthrough in UK battlefield tech development). The spectacular use of ...


1

Individuals and interactions over processes and tools Go back to the user and ask for more clarification, details, etc. I know this isn't always possible and can be annoying to both sides, but it's better than coding in the blind. It may help both sides understand what everybody really needs to know before coding. There are plenty of techniques to make ...


1

I have been part of Retrospectives where people were geographically located in different places. In such cases Retrospectives were conducted over video conference. We used an online tool (ideaboardz) to collect the retro points and action items. Rest of the activity used to be as it is. The usual stuff. As for the honesty and participation is concerned, ...



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