New answers tagged

0

A lot can be done with the use of mocks and stubs. The traditional approach might be something like this: Developer codes feature QA writes test case at the same time When developer has finished coding they hand over to the QA to run a manual test As you mentioned this leads to the back-loading of sprints and to incomplete work. The alternative is to do ...


1

Your analysis of a problem existing may be correct. Your proposed solution is not. Your boss is entirely correct. Development and QA require completely different skillsets. You might find people who can do both, but even then, why would you waste their time with QA tasks when you can just hire a lower-wage QA to do it? Now, you say, We're continuously ...


3

My preferred approach is to do a 'hello world' story. Pick something small or trivial on the backlog and decide that you will be delivering it using continuous delivery. Inform your stakeholders that although they will see only a small amount of value from this story, it will be the first story delivered using continuous delivery. Help them to understand the ...


0

I think a "common name" in parens behind whatever non-memorable number system you use is fine and beneficial, if not fun. They could even correlate to the number. before: 2021W31 after: 2021W31(Reggie)


0

There are different ways to handle it. My preferred approach would look something like this. First, the work should be expressed in the Product Backlog. The work in the Product Backlog is the work that is necessary to improve the product. The INVEST criteria are a good way to decompose the Product Backlog items into small, independently deliverable chunks ...


1

Here's what I would do next: "take your concerns back to them." Alert them to the fact that you perceive that the standards are not being "properly" adhered to, and "ask them why." Listen very carefully to what they say. The technical issues and concerns, particularly with SQL, have already been brought forward in this thread ...


2

As you wrote, it's likely a combination of education and process task. The coding standard needs to be understood, digested and practiced before it becomes a habit and part of the professional ethos. I find that Definitions of Done are very useful to educate the teams and get these habits embedded in the normal way of working. You could add a dedicated ...


1

In our project we know upfront that we will not able to complete all tasks of a user story in single Sprint hence we always ensure that only task can be completed is assigned in current Sprint and other tasks are assigned to next sprint. We ensure that each PBI is also marked as Done only in the Sprint in which all its tasks are completed. I agree with ...


1

In the last sprint, there were some standards that were missed by the Developer, and also missed by the Reviewer. Why it was missed? Was it due to lack of time or lack of intention? If it is due to lack of time, then when you plan next sprint, the development team should keep aside estimates to make sure they check that the code they develop is adhering to ...


0

There is an alternative method to track velocity that is especially useful for new teams or teams still trying to master the estimation exercise. And that is to simply count how many stories that team can complete in a standard iteration. Not points but whole stories. In theory the story size should be taken into account when measuring velocity but in ...


0

The purpose of velocity, and story points, is to aid the development team in answering one question: Given our current understanding and knowledge, what is the scope of work that we can confidently deliver during this Sprint? Scrum, in particular, is meant to be a framework for developing a product in a complex environment, meaning one where the work ...


0

Project management normally includes a quality management plan; having coding standards is one of the steps, but you've got to plan a way to do quality review and acceptance. Some teams break out the quality acceptance function into a separate team. Scrum teams (as I understand them) accept the responsibility for delivery an acceptable quality product as ...


5

In my experience the most effective coding standards are those that are driven directly by the developers. An approach I have seen work well is to have a developer community of practice that discusses coding standards and agrees them by consensus. By introducing standards in this way the developers have a buy-in to them being successful. If they feel a ...


7

In order to be cared about, standards must be understood. You say that a checklist[...]/checkboxes [are not] ideal because On previous teams, the coding standards were like an ethos that was upheld by the Application Development Manager, believed in by the team, and taught to new Devs when onboarded. What I take from this is that your primary concern is ...


2

In this case, the easiest solution would be to use some linters for the code you produce, be it SQL or something else. See also: Lint (software) List of tools for static code analysis These tools will automate some of the rules, but they only cover syntax. You still need people to agree together on a standard of quality and then stick to it because it's ...


2

An effective way to define product ownership is to use customer journeys. Each product owner is assigned one or more journey. Examples might be: Registration journey Onboarding journey Subscription journey Purchasing journey By thinking in terms of journeys we give the product owner the chance to influence the experience of the customer. For example, a ...


0

The role of Scrum Master on a Scrum Team can be generalized to that of an agile coach. Therefore, one reasonable model for looking at the role could be the Agile Coaching Competency Framework: So, can you be a Scrum Master without any technical experience? Sure. Regardless of your background, you'd still need competency in agile-lean values and principles, ...


3

So does PO need to attend every Sprint Demo? The Product Owner should be getting visibility of the work being done by the team throughout the sprint. The intention of the sprint review ceremony in Scrum is not to inform the Product Owner of the work that the team has done, instead it is to inform stakeholders who are not involved with the team day-to-day ...


1

You are quite right that estimates are hard to get right and that the real amount of work will include an error component. However, there are a couple of factors that work to reduce the impact of these errors: The team is estimating on lots of backlog items so errors should have a tendency to cancel out (e.g. high estimates will cancel out low estimates). ...


1

In a nutshell, Scrum is explained like so (emphasis mine): A Product Owner orders the work for a complex problem into a Product Backlog. The Scrum Team turns a selection of the work into an Increment of value during a Sprint. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint. Repeat The idea with running sprints is that ...


4

Velocity measures how much work the team can complete per sprint, given a stable team and a common understanding of the complexity of the items that they work on. It's usually measured in number of story points, or sometimes, if PBIs can be split into similar sizes, you can even count number of PBIs completed per sprint and use that as your velocity. ...


1

If you are using Scrum, the expectation is that the Scrum Team creates "a valuable, useful Increment every Sprint". Prior to the November 2020 Scrum Guide revisions, the term "potentially releasable" was used. There is no "Sprint Demo" in Scrum. The event is the Sprint Review. A demonstration may be a component of a Sprint ...


3

You're exactly right. It can be great to build a robust set of regression tests, but interface-dependent automated tests are more fragile than many other testing approaches. Ideally, you should only test UI-specific behavior through the UI (including automated selenium tests). So, for example, if you want to test if an error message is displayed, this sort ...


0

The answer to this will depend upon the story and the definition of done for your organization. You could develop the test for a feature in one sprint and the feature in another. Likewise if your definition of done doesn’t include a test a test may or may not be added later. I would recommend that you focus on what you want to get done, and use scrum to ...


5

In the Scrum framework it is up to the team to decide how to deliver backlog items. Many teams do adopt a TDD / BDD style approach although this is usually accompanied by exploratory testing and UAT as well. When it comes to managing TDD with continuous integration, the answer to your question is branching. Developers are normally expected to create a new ...


8

Do QA-engineers write automated tests for the feature at the same time as developers write code of the feature? Ideally yes. You need the two activities to be performed by a collaboration between developers and testers. TDD is another techniques that can be used. The idea is to move away from the behavior many are used to, which is for developers to write ...


0

I'm a little perplexed by this situation. In my organization, a story does not get into the Sprint Backlog until it's already written and all the acceptance criteria are verified and signed off on. So I am always working on the PBI items, getting them ready for the next Sprint. I am usually at least a Sprint ahead; that way we never have this problem. Hope ...


3

You say you can get audited and that you do some R&D activities too. Does the company you work for need to comply with specific regulations or standards? If yes, that would be the where I would start. If your auditors or tax people require certain information to be available then try to identify the work that falls in these categories and split them from ...


4

Between Why do you need to track 'Features'? Never said I did. The problem is historic to this team. and Why do devs need to track their time Primarily because some activities qualify for R & D tax refunds and some don't. My suggestion would be to reduce everything down to just two 'Features': R&D Tax Refundable Non-R&D It simplifies ...


Top 50 recent answers are included