We’re rewarding the question askers & reputations are being recalculated! Read more.

New answers tagged

0

Obviously all of the methods we now call "Agile" were developed from scratch by the team(s) involved, so of course your team can do so! The key phrase, though, is your team. This is what is meant by "self-organizing teams" in one of the Manifesto principles. Gather everyone in a room, walk through the Agile Manifesto, and facilitate creation of the team ...


0

- Agile - In the Agile methodology, the role of technical lead is viable. But it’s important to understand if your team really needs this technical lead. If the team is young, probably they need a leader who can coordinate the work process, while also offering some insight. - Scrum - In Scrum, there are only three roles: product owner, scrum master, and ...


0

The simplest way to answer this question is to validate your approach against the Agile values. Responding to change over following a plan Does your approach allow you to respond quickly and with minimal cost to change? The change may be to the requirements, may be a result of technical uncertainty, or may be due to other factors. Will the milestones and ...


0

Don't wait for the deadline of the task to receive customers’ feedback If you have stories that cannot be finished because of missing information from your customer, this means that you are not exactly agile. How agile works: The development process has some milestones, in which micro-releases of product are made and feedback from your customer is received....


0

Since you are "stuck" with this person, your other option is to improve their skills. One possibility is to pair them with a different dev each sprint, along the lines of my answer here: https://pm.stackexchange.com/a/27497/37642. Another is to put in cross-training stories, so each sprint includes formal cross-training between one dev and this person. Look ...


0

Problem Statement: If I understood your issue correctly, then it is that QA engineer not able to understand and perform testing efficiently without multiple inputs and help channels. Analysis: Well what's missing is, How are these tasks defined and communicated? If the user stories are defined in well format explaining the tasks in functional and technical ...


1

Developers must validate their changes by doing their own unit testing on the product and then she does the user acceptance testing with users. I know this is contrary to the agile guidelines but her limited technical acumen means she is incapable of doing anything more than user testing. I don't understand this statement. If you have somebody on the team ...


0

Agile approach ≠ lack of documentation If you need to document really important things, such as resources, working hours, equipment required, of course, you can do it. I’d rather say, you should do it. Using the agile approach you may create only summary documents that picture the ongoing situation. An interesting fact is that in the traditional ...


4

A remark first: this person is not "less competent", they simply have a different job than yours. Their job requires communication. The question is how to get them to communicate in a way that does not disturb you. You have told them what you prefer. They did not listen. The next step is to bring that up in whatever improvement process you have in ...


0

agile project: either the first iteration of a brand new solution leading to an MVP, or a timeboxed mission to achieve a specific scope/goal I am struggling to see why this is necessary and why the Agile product evolution approach you mention cannot be used instead. A brand new solution can be developed using an iterative evolution. You may decide to not ...


0

Because Agile has no single authoritative body, many terms and concepts are up to interpretation. That is not inherently problematic - these slight differences in interpretation often help people find the solution that best meets their needs. So, to that end, if what you are describing works well in your context, enjoy the success. However, it is certainly ...


0

One of the core elements of Scrum is: Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available. If a story is awaiting answers from your customer at the end of a sprint then it is not "done". This will then be reflected in the number of story points that get completed in the sprint and so will ...


2

There are already several good answers mentioning use of tools like PIP, peer review, and TDD, but I’ll mention one thing that strikes me. In your question you state I have a person in my team with average experience that always do the task exactly as requested as output but with low quality. But if he did it exactly as requested, you wouldn’t be asking ...


1

There have already been good answers to this question, but you may also want to consider using a test driven development (TDD) approach. For example, have the developer first write automated tests that validate the acceptance criteria on the user story. Only once those tests are written do they proceed to the implementation. This approach has several ...


0

INVEST is a principle and not a rulebook. As Scrum teams we endeavour to make as many of our stories as possible follow the INVEST principle. You have wrapped some setup technical tasks into the first story, but there may well be nothing stopping you from moving them to another story. Say, for example, in the first sprint planning meeting it is decided ...


0

There are a lot of drivers that can cause or contribute to an individual's performance, one of them being that he can be simply a low performer intrinsically. Once you have ruled out the various external drivers to performance as the cause or contributor to his performance, than focus on his tasks with measurable expectations and use a formal Performance ...


2

Sprints and milestones are tools you can use to break a release, like the release of a new feature, into smaller and incremental steps. Most software teams are already working with sprints, by committing to complete several tasks in the next 2 or 3 weeks. One of the advantages of working in sprints, it’s that after you decide what work goes into each sprint,...


0

This question appears to be based on a false premise. It requires that you accept unclear work into a Sprint. I'd argue that if you have insufficient detail to get work to a done state and receive feedback from your users or clients, you shouldn't start the work. In some cases, if you can't get full clarity from your users before starting work, it may be ...


2

Since you added the Agile tag, I will answer from that perspective. In Extreme Programming (with "peer programming") and some implementations of Scrum or Kanban, teams will require a quality sign-off from a peer on the team before the requirement or "user story" can be considered for final acceptance. This puts what I call "positive peer pressure" to work, ...


2

If you read the Agile Manifesto and its principles, you will see wording like: Individuals and interactions ...; Customer collaboration ...; Business people and developers must work together daily throughout the project; The most efficient and effective method of conveying information to and within a development team is face-to-face ...


1

We conduct risk assessments during our projects. The resulting risk register enables us to share evaluations of our improvement and tells our team's story of changing and adapting.


2

Your list of stories is perfect as written, John! The methods we now call "Agile" share in common the idea of iterative development, per William Rouse's seminal article on managing software projects (1970). They assume you will create a basic functionality, then add functionality on top of it. Per Bogdan's excellent point, most tools I've used have a ...


0

A short answer I have found easy to implement in many different kinds of teams: Create a user story for the discovery session, and treat it like you do any other story. That is, rank it high enough in your Product Backlog to get into the sprint; estimate and task it out (if you do those things); add the developers who choose to be involved; and if that ...


0

Tying into Daniel's answer, several Agile methods allow for aggregating stories into a larger story some call an "epic" that describes a larger deliverable like a feature. Each sprint does deliver a "potentially releasable" outcome--a variant on Daniel's phrase--like the "account section" you describe. And there often is value in showing that to the customer ...


2

Iterative and Incremental Work Can Have Prerequisites In the typical agile development model, stories build on one another. In this case, "independent" doesn't mean it has no relationship whatsoever to other user stories. In the context of INVEST, it simply means the story can be worked on or tested separately from other product backlog items (PBIs) ...


7

You cannot totally eliminate dependencies. Some story will depend on another, some feature will need another feature to be built first, some new feature will be desired only after you see and interact with some already built feature, etc. That's just the nature of things. So the "Independent" in INVEST isn't about eliminating dependencies, it is about ...


4

Think "Release" Instead of Stories to Track Value User stories are not meant to be a measure of business value. As a rule of thumb, each Sprint should deliver a potentially-releasable increment of product, but nothing requires that each iteration deliver X amount of value. User stories just represent INVEST-sized units of work that collectively deliver the ...


4

The short answer is that there are many different cases where delivering a complete, market-ready segment of functionality is not reasonable in one sprint. So, let's start with the simple answer: each of those things you list is valuable to the customer and you could make it "potentially shippable" in the sense that it is technologically and quality-wise ...


0

document our current methodology How quickly will this become out of date? Will the document be continually updated? Will enough people read the document to ensure its value? Agile teams tend to shy away from documentation unless they are sure of their value. share our team's story of changing and adapting One of the Agile values is Individuals and ...


2

You might be looking for a Project Charter. This kind of documents varies a lot from project to project. With regards to tools and techniques, I share a part of the linked article. The Agile community has appropriated a number of different techniques or notations that have proven useful to capture high-level project information. For instance the “...


1

For the sake of argument, ignore for one second the two entry level developers. You now have a team of just the two experienced engineers. Do you see any issues in implementing Scrum now? Probably not. You will develop in sprints, you will have sprint planning, you will do refinement, you will have retrospectives and reviews, build and deploy product ...


5

Product Backlog Refinement The PO comes with more opportunities for automation. These opportunities need to be reviewed, sized and an effort estimation need to be provided, i.e. a discovery session is needed. What you're calling a "discovery session" is actually a defined event in Scrum called Product Backlog refinement. [Refinement] is an ongoing ...


2

Who has authority? the designated group leader and Product Owner Here's one of your problems. As a Scrum Master, it's your responsibility to ensure that the Scrum Team (including the Product Owner (PO)) understands and follows the Scrum process. But the PO is your 'designated group leader'. Your boss. You need to clarify expectations from the management ...


5

The development team is already busy working in the current sprint One of the principles in the Scrum Guide is that a Scrum team spends time during the sprint refining their backlog of work. This can represent up to 10% of the time in the sprint. In your situation this backlog refinement would include discovery sessions, review, etc. How the refinement is ...


2

he thinks the idea of a time-boxed sprint would produce additional stress in the beginning. I disagree with this assessment. The time boxed sprint is not intended to create a stressful deadline. Instead it is a natural break point that allows the team to get feedback and to inspect & adapt. A Scrum team that is a mixture of experienced engineers and ...


1

Agile is a mindset and as Ashok mentioned earlier, one of the values recognized by Agile teams, is prioritizing working software over comprehensive documentation. If said SRS or any formal documentation is needed for business ore compliance reasons, it can be created as part of the user stories / or tasks within a story. Be mindful however not to go down the ...


0

Working software over comprehensive documentation One of the four main declarations made in the Manifesto for Agile Software Development is: ...we have come to value: ... Working software over comprehensive documentation If I were the buyer, I will rather take a copy of the Jira (or other issue tracking software) than an SRS (Software Requirements ...


0

I've done more research. And from the resource below, it sounds like it is something that is not part of agile (since in Agile you are not bound to any strict list of requirements from start to finish), but can be incorporated into it if required. Does Formal Requirements Documentation Have A Place In Agile If you really need to have a formal SRS, then ...


7

Ongoing - track your velocity. Document every roadblock and inefficiency, caused by her or otherwise. Bring them up in the Sprint Retrospectives, speaking in neutral language - trying to find solutions to problems, not people. If no solutions can be found (and implemented), then you need to do two things: start working these inefficiencies into your ...


9

She does not give acceptance criteria This is not a problem if the Product Owner is happy to talk through the stories with the team and clear up any details. The team can even create their own acceptance criteria as a result of the discussions if they find that useful. If the Product Owner is not willing to spend the necessary time explaining the stories ...


0

Part of the challenge is that "As a user" doesn't tell me who this is for, so it is hard to say if it is valuable. If it is "As a developer of 3rd party websites" then yes, REST API would be an independently-valuable. However, if it is "As a prospective car buyer" then it is certainly not independently-valuable. To take this further, let's say it is the ...


2

Should I try splitting this story at all? If it follows Estimable, Small, and Testable, no. If it doesn't, maybe. Should I create a separate story for creating a REST API? [...] it appears as a complete vertical slice. I disagree. Consider the I and the V. Each story must independently provide value. Say you make your API and do nothing else. You then ...


Top 50 recent answers are included