What To Do When They Want To Know Cost Per Point w Troy Lightfoot
Categories:
,
Agile,
Agile Estimation,
Agile Uprising,
Dave Prior,
drunken pm radio,
drunkenpm,
Scrum,
The Reluctant Agilist,
Troy Lightfoot
Categories: , Agile, Agile Estimation, Agile Uprising, Dave Prior, drunken pm radio, drunkenpm, Scrum, The Reluctant Agilist, Troy Lightfoot
|
This issue often arrives wrapped in requests that are pure in their intent and seem to be reasonable requests from the business… How much are we spending each month and how many points are we delivering for that spend? or Since we are now estimating work in User Story Points, we need to be able to determine how much to charge for the work that clients are asking for. So how much does a point cost us? or We need to evaluate the change requests so we can decide which ones to move forward with and which ones to reject. We’re estimating them in User Story Points, which gives us a relative idea of risk, complexity, and effort, but not cost. We need to be able to translate points to dollars so we can understand if the value we’d receive from the change is worth the cost. I had a student recently who was qetting requests like this from the business, so I asked Agile Coach Troy Lightfoot to join me for a podcast where we could unpack the issues that often come with the cost per point question, the pros and cons of tracking it, and some things to take into account when you formulate your response to the request. drunkenpmradio · What To Do When They Want To Know Cost Per Point w Troy Lightfoot Links from the Podcast
Contacting Troy
|
What do you do when they start asking for cost per point? Test Driven Development and Mobbing for Non Developers
|
Summary: You don’t have to be a developer to use Test Driven Development and Mob Programming. Last week on Twitch Amitai Schlier & Troy Lightfoot led Dave Prior and Rachel Gertz (neither of who can program) through an exercise in remote pairing with TDD. If you come from a PM background, you’ve probably heard developers talk about Test Driven Development and you may even get the basic idea behind it - build the test to prove something works, then build the thing that passes the test. You may also have heard about Mob Programming - the set of practices put together by Woody Zuill that takes the idea of pairing and extends it to the whole team. In mobbing, an entire team builds everything together. They share one keyboard and rotate the person typing at timed intervals. This allows them to develop cross-functionality, to learn from each other and, basically, QA as they go. These are both topics I’ve been interested in for awhile, but I’ve never had an opportunity arise that gave me a chance to actually try them. But, last week I had the opportunity to participate in a unique experiment that not only let me learn more about each of these sets of practices, but gave me a The entire experience was a blast and I’ve developed a new found appreciation for the entire though process and discipline that goes into using Test Driven Development and trying to mob with a team. I’d encourage you to check out the video on your own, or with your team and maybe even try to replicate the experiment. I think this would work great as a team building exercise as well. Most of the time I felt like I was playing a board game with a bunch of friends. |
