586 reputation
15
bio website theagilecoder.wordpress.com
location
age
visits member for 1 year, 11 months
seen Nov 19 at 13:38

Solution Architect with 15 years of experience in the software development field. Into ALM, integrations, software architecture, and stopping slapshots.


Oct
21
comment In an Agile Environment, who is responsible for software architecture
Thank you gnat, I have tried to edit it to make it more clear as to what my intention had been for responding to the question. I made a few leaps in my head, but forgot to write them down :)
Feb
4
comment Criteria for prioritizing product backlog
It only goes against the paradigm if the system is unusable with the code in place. If you are making changes that can't be stabilized within your sprint or hidden so as not to impact your users, the story is probably too big and needs to be broken into smaller pieces.
Feb
4
comment Criteria for prioritizing product backlog
For risky items we attempt to chunk into more palatable pieces that can be delivered iteratively, and then resolve 'showstopper' bugs that would prevent delivery. Essentially, the story isn't "Done". Other bugs that are lower priority go to the backlog to be prioritized alongside other work.
Feb
4
comment Criteria for prioritizing product backlog
That's why value is also part of the equation. You don't want low-value high-risk items first. If you have high-value or mid-value items with risk, you should do those before high-value low-risk, because you don't have risk in doing those later. Ask your devs: if you have 2 days left in your timeline, do you want to start on some easy stuff, or the riskiest stuff in the project? That's why you raise priority on riskier items: project risk mitigation. With that said, if you can deliver minimum shippable without a risky item, that probably indicates a low business value anyways.
Jan
21
comment How to introduce Scrum in a company accustomed to Scrumbutt or Scrumfall?
Well worded PDR, this is exactly what I've had to do in similar situations. Actually, if the managements is already open to 'agile', that makes fixing the problems a little easier because you don't have to sell them on what they've already bought.
Oct
31
comment What happens with project backlog if sprint due date is missed?
I think I'm just confused in your use of the term 'velocity report', as it is different than how I use my velocity report. I use the velocity report to track business value delivered, not effort spent, but I can see what you mean. I can definitely see the benefit of you also tracking the effort your team spent in R&D versus maintenance. In my opinion, you still should only recognize the'estimates' that were successfully delivered, but you may want to make your velocity report have multiple bars (hours delivered, hours spent, hours on maintenance).
Oct
30
comment What happens with project backlog if sprint due date is missed?
I guess it comes down to what your velocity report is being used for. Are you tracking how much effort was put in each sprint? Or are you tracking how much business value your team delivered? You can put in a full 40 hours of effort and deliver absolutely no business value. Or you can put in 10 hours of effort and deliver all of the business value for a story. For my own reporting to my clients, the hours spent is only of interest in terms of billing. Otherwise, they just want to know how long until they get what they need.
Oct
29
comment What happens with project backlog if sprint due date is missed?
This is also why most estimates at the story level are usually not in hours. The 'value' you are recognizing is not the same as the hours spent delivering it. If you are running a scrum-like reporting of velocity, you would normally be reporting on points of value delivered, and then also tracking hours remaining on tasks. You may want to track hours spent as well to know about your efficiency on tasks, but I would normally consider that an extra tax on the developers that doesn't really give you much value for the effort put in.
May
29
comment Task-based authorization for user stories
I should add, if you are trying to write the user story, you should define it without the security implementation details. Write acceptance criteria that define in what way the user is restricted (or not restricted) and let the development team figure out how to make the system meet that criteria. Your testers should then write test cases based on the acceptance criteria to ensure that the implementation meets the needs.
May
29
comment Task-based authorization for user stories
Perhaps you are right. But manager might only have highest authorization within a specific department, or perhaps they have specific users over which they have highest authorization. When you go to implement the story, you'll take the acceptance criteria and then define your security model to allow users like that to have the correct access. If task-based security lets you do that, go for it!
May
23
comment Increasing User Changes/Requirements in Agile Methodology
There is definitely a limit to what you can do with budget increases. If you spin up a second team to do a lot of work, you then need increased overhead to get the two teams integrating together. If you just add budget for overtime from the existing team, you minimize how much extra you can do and tend to get your team burned out. As with anything, moderation is key.