Tag Info

New answers tagged

0

I think what you are looking for is extreme programming. Most of the times if we are unable to complete the work in a given release The triangle of time / scope / cost allows you to increase one if you reduce another, not just force all three to be better, this results in the hidden fourth variable taking a hit i.e. quality. additional teams are ...


5

Is this acceptable in agile scrum? Define "acceptable". In some environments, it's fine. In most, it is prohibitively problematic. That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to ...


1

Most developers are confronted with either creating crappy/less manageable/unscalable/not quite so perfect software in order to meet an arbitrary deadline or they get fired. One reason good programmers are considered good is because they're able to stand up to this because of their reputation, influence, persuasive skills, threatening to leave, etc. Being a ...


5

Without being in a position of team lead, the options are somewhat limited. There are different bases of power. The individual in your question won't have legitimate power, as they are not the lead or manager and they don't have the position to drive change. However, depending on their personality, they may be able to develop a position of referent power or ...


29

I wouldn't focus on the quantity, but rather on substance. The number of affected files during a group of refactoring operations is as irrelevant as the LOC you write per day. An extreme example is the renaming of methods to follow a convention. It may affect thousands of files, but is barely more important than a refactoring focused on two files which ...


6

Agree up front how much refactoring is to occur on each ticket. This is done as a team. If that developer wants to do extra stuff, bring it up and decide whether it is OK. Keep things scoped properly. There's nothing worse trying to explain to a boss why the team broke something that wasn't in scope. Also, verify refactoring is actually improving the ...


2

To me this sounds like you and your team mate aren't on the same page when it comes to the level of quality required of the project. I recently had the same problem with a team. What worked for me was determining the ideal design we all agreed on for every part of the project. The repository would use CQS, the MVC controllers would be very thin and ...


3

how many files should one be touching at max? Theoretically speaking you can go on refactoring indefinitely because there is no perfect codebase. One way to get around this that has worked out for me and my team is to identify these areas that need cleaning, make tickets out of them (call it technical debt tickets or anything else along those lines) ...


-1

Product Backlog Hierarchy is pretty much dependent on the product size and its modularity (number of product areas defined). For small Projects: Epic > Story is more than enough; and you call either the "feature". Large projects might become alike to: Novel > Theme > Epic > Feature > Story The best example might be the following: Novel = MS Office Theme ...


2

Just to rephrase the question. You are blocked on scrum adoption because of the bug in JIRA? That sounds very wrong to me. Scrum is a project management methodology, it cannot depend on tools, tools are meant to be assisting with routine work, not impede it. Hence, my always advice, use physical board, see the progress looking at real tangible things. ...


0

It depends. The level of details in acceptance criteria may very depending on the type of story. Consider creating a user story for a web page or for a new programming language? I suppose different level of details will be needed to accept the story (meaning it is done correctly). I find that the more detailed the AC are, the less are the chances of ...


5

Personally, I would say an acceptance criteria of "Must be an <h1> tag" is not an appropriate acceptance criteria, unless the PO would be willing to reject the story if the team used some other tag and applied styling to make it look like an <h1> tag. In other words, is the use of <h1> truly a required part of the solution? I would ...


2

More examples of interruptions will be helpful to understand the reasoning why your skip manager or another stakeholder requires "stop everything and do this" type of work. For "put a PPT together to approve", could this be the lack of transparency up? Does your team invite all the stakeholders to attend the demos showing the status/progress of sprint's ...


8

This is the Product Owner's job. The whole point of the product owner is to act as the point of contact between all the stakeholders (including people like someone's boss's boss) and the team itself. In theory, the rest of the team should only ever have to deal with the Product Owner. The Product Owner goes and does all the work of talking to various ...


0

Some devs that were used to working under the old system complain that this doesn't give the developers credit for completing the work that they were assigned Did they really complete the work in time when there is not enough time left in the sprint for completing the test cycle? Maybe, maybe QA needed more time than expected, who knows, but the ...


2

It is your team's responsibility -- the whole team -- to make sure everything is done. If the devs are finished coding and there are still tests to write or perform, they should pitch in and help the testers. There shouldn't be any "open developer time" -- why penalize your testers by giving the developers free time? The developers need to help with the ...



Top 50 recent answers are included