New answers tagged

1

I'm going to state some obvious facts but bear with me. Takeuchi Nonaka's article in HBR talks about a New Product Development Process, does not talk about Agile Software Development, does not talk about Scrum as it is defined by Ken & Jeff: Scrum (n): A framework within which people can address complex adaptive problems, while productively and ...


1

The Agile Manifesto for Software Development is about a mindset shift and a cultural change. Per definition no simple technical definition of Agile in this realm. Agile is cultural transforming journey for all – individuals and the organisation, with the goal of becoming agile i.e. change the culture of the organisation and the mindset of the individuals. ...


1

It is important to understand that Agile Manifesto is a criticism of ways of work that were dominant in the time it was written. When you understand how software development was done back in that time, things start making sense. Customer collaboration over contract negotiation Back in the days, it was (and sometimes still is) perfectly normal practice for ...


0

Another perspective to describe the two principles is the following Customer collaboration over contract negotiation In many non-agile organizations, projects are started with armies of product managers/ business analyists and project managers collaborate together to make an agreement. Then the project starts. Period In an Agile mindset, this is totally ...


1

Additionally, laud bug fixing. It must be held in esteem by the business, and treated equivalently (if not superior) to delivering a feature. Otherwise why would I fix something when no one cares and also risk being rebuked for wasting time/resources/not delivering business value.


4

Scott Duncan write a short book called "Understanding Agile Values & Principles: An Examination of the Agile Manifesto", published by InfoQ and freely available in PDF format, that takes a deep dive into the Manifesto for Agile Software Development and its values and principles. What follows is a summary of his thinking. Duncan relates "customer ...


5

First I'd like to say that the points in the manifesto are not mutually exclusive (e.g.: working product over docs might also overlap with collaboration over contracts) Having said that, I think the best way to explain where points 3 and 4 don't overlap is by example In an overly contractual setting each party will usually defend their rights even if it is ...


11

Show me someone who cares. Fixing bugs from an unfeeling checklist gets to be a drag. If the fix will put a smile on someone’s face, let me see it. Don’t make me work alone. Every bug fix is a chance to learn something and it is great fun to share something you learned with someone else. Let me do more than just fix bugs. Sometimes bugs show you a ...


3

Some additional thoughts beyond Albuquerque's answer, which I fully support: Drafting an SRS is one way to capture the requirements. Unfortunately it requires to think about all the requirements upfront, at a moment the analyst may not have a full understanding of the domain, and the user don't yet get what the system can/will do for him/her nor what the ...


4

YOUR TEAM must know what is good for YOUR TEAM The amount of detail the user tasks should have are team dependent. In that sense, it is not possible to know if for YOUR TEAM it will be good to attach such artifacts or not. For teams that are starting to get used to working with user stories, having to always attach artifacts to stories would just create ...


4

Story points at least arguably should never leave the team room -- it's not something higher-ups need to know. However, if they hold your feet to the fire and insist on a number, and if you've been at it for a while and your team has delivered a product before, just do basic math. Add up all of the story points for the past six or twelve months, and divide ...


6

You don't convert story points into money. The cost of a software development effort is a function of the team for a period of time, perhaps considering resources if you forward those costs along. However, story points do not convert to time, so you cannot use them as an input into cost. Story points are also highly volatile, so even if you tried to convert ...


3

Story points are supposed to be abstract, they are only ever intended to be used as a relative measurement that is quick to estimate. Once you attempt to translate story points into a cost (e.g. 3 points is 15 hours) you get a false sense of accuracy, and your estimates become much harder to come to a consensus on. If you need to give time / cost estimates,...


1

The Scrum Guide does state: the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product which means in the absence of a Definition of Done (DoD), it's on the Development Team to define one. However, IMHO, you can't ignore the "if" that precedes this statement: If "Done" for an increment is not a convention ...


Top 50 recent answers are included