In this interview, Michael Nauman, a testing lead for AutoCAD Web, explains how we can go beyond basic agile principles. He digs into the current state of shift-left testing, the importance of aligning your DevOps with your automation, and using agile as a starting point on your quality journey.
Today, agile teams are being asked to do more than ever before. The notion of a T-shaped person, created by Tim Brown (CEO of IDEO) in the 1990s, describes a new breed of worker—one who goes beyond the standard, assigned role. Mary Thorn believes that the roles of team members can stretch...
In the past two decades, Scrum has become the standard for agile development, with more than 90 percent of teams today using Scrum to deliver working software. But, as Scrum starts into its third decade, it’s not the fresh-faced process framework that came into the world in the summer...
Using the iterative and incremental agile development framework Scrum should help manage product development, but some teams still have difficulty delivering features in a predictable manner. This organization decided to address the mismatch between what was being committed and what was accomplished by doing an experiment in work transparency.
Estimation uncertainty in software projects is often not driven by the difficulty of the problem we are trying to solve, but rather by the health of our codebase, the quality of process, and how much discipline we have in our management practices. If you want to improve your estimates, then agile and #NoEstimates thinking can have the biggest impact on your team’s success.
I have just taken over responsibility as a a scrum master and although i have worked under a scrum team before for a year but i always had difficulty in estimating according to story points. So in my first prokject as a scrum master, I took a risk and though to map story points against hours and it went very well. Here is how i mapped:
Points - Hours
I like your idea very much. It is similar to the way that I prefer to estimate, with two key differences:
- I recommend a 'modified' Fibonacci sequence: 1,2, 3, 4, 5 as the point scale. 8, 13 are allowed, but represent stories too big to plan. Why do I add '4'? Because 1, 2, 3, 5 has a big hole in it...
- I use the baseline recommended by the Scaled Agile Framework (SAFe) methodology of having a one-point story representing the unit of effort required to start, execute and finish a story to the definition of done in one sprint day. We loosely define a sprint day as the six hours of an eight hour day where people actually work. Thus, we allocate eight points of work during a typical sprint for a typical team member.
That said, I am amenable to making 'half-days' a reasonably consistent substitute for full days. It is important that your decisions reflect the will and planning effectiveness of the team. Always make sure to be flexible in interpreting how agile should be implemented. Also, ensure never to freak out and get brain lock over estimates. Remember - they are ESTIMATES.
Transforming a software development team to agile may not go as planned. The real change requires a phased approach to earn agile acceptance. That mindset must extend beyond the team to the entire organization.
- Little, Jason. “Estimating Bugs in Order to Get Better at Estimating.” Agile Coach (blog). October 24, 2008. http://www.agilecoach.ca/2008/10/24/estimating-bugs-in-order-to-get-better-at-estimating.
- Christiansen, Jonathan. “Four Stages of Social Movements.” EBSCO Research Starters . https://www.ebscohost.com/uploads/imported/thisTopic-dbTopic-1248.pdf.
- Galbraith, Jay. “Star Model.” Galbraith Management Consultants. January 6, 2016. http://www.jaygalbraith.com/images/pdfs/StarModel.pdf.
- Wade, Geoff. “Cracking the Change Code.” Onirik. https://dl.dropboxusercontent.com/u/30239194/leanchangemanagement/cracking-the-change-code.pdf.
- Gibbons, Paul. The Science of Successful Organizational Change: How Leaders Set Strategy, Change Behavior, and Create an Agile Culture . New York: Pearson Education, 2015.
- Version One. “The 10th Annual State of Agile Report.” Agile Annual Report. 2016. https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf.
- Lean Coffee. “Lean Coffee Lives Here.” http://leancoffee.org.
- Harnish, Verne. Mastering the Rockefeller Habits: What You Must Do to Increase the Value of Your Growing Firm . New York: SelectBooks, 2002.
I'm desperately looking for a bit of help! We are a small scrum team who recently turned agile (yay). The previous pm manager preferred using time estimations which was easy for pm's, not the agile-loving dev team. I want to teach my team how to switch to story point estimation and the major concerns of the team are - How do we explain cost to clients per sprint using points? Do we just take the budget total, divide into sprints (based on hours in a sprint) and cost this for a big project?
I have a very reluctant team so any help would be greatfuly appreciated!
Believe it or not, that is the heart of agile project funding. If you can make a stab at what your team can produce in a week, the cost is the cost of the team and the revenue is the value created in an iteration.
Important to note: estimation is always done just-in-time, so estimating work that is further away will be less accurate. If your team estimates honestly and transparently, over time you will get better and better.
The temptation to try and estimate in TERMS of time is not recommended - try to think in terms of complexity. You can think of complexity as being roughly linear with the number of things you have to DO in order to finish a story. This very roughly equates to time, but thinking in terms of time alone has been widely proven to be much less accurate.
Recommended watching for your team: Cost of Delay: Theory and Practice
Kirsty, think about two kinds of estimation. One estimation is for an order of magnitude, for management. One is specific for the team, "What can we do in this next iteration?" (I assume you work in two-week iterations.)
Now, the problem is this: Any kind of estimation you do with a new team, or on a new project where you don't know the domain is suspect. You need to provide that kind of an estimate with some uncertainty. I like 3-point estimation or percent confidence. Managers don't like this, but that's what they need to plan.
If you want to plan what you can do in an iteration, why use story points at all? Why not just count stories? When you count stories, the PO has an incentive to make each story smaller. The team has an incentive to work together to move that story to done.
I'm not talking about tasks, I'm talking about a story that has value to a customer.
As for "when will this project be done?" only the PO can answer that question. What is an MVP? What are the project's release criteria? If the PO defines and the team delivers MVPs, you might be able to end the project early. And, the PO can change what goes into the next iteration, to guide the product growth.
When you use features (or stories), what the customer buys, you have these benefits:
- You can measure the cycle time for your features. You can then provide an average cost per feature. (Take the daily run rate for your team and use cycle time. A 2-day feature costs 2x the daily run rate.) This also incents the customer to work with the PO to create smaller stories.
- You can work with the customer to explain what "average" means, which is not every feature, but the average. Some features will cost more, some will cost less.
I don't know how to use story points with customers. I suggest to all of my clients that they not use story points. Instead, I recommend that they use cycle time and measure the average cost for a feature, if they need to provide cost/schedule information.
The big question I have is this: Can your team deliver a story every day (or every other day)? If not, your stories are too big and your estimation is off. Reduce story size and estimation becomes irrelevant. You count, not estimate.
Yes, the PO has a bigger job. That's the point of agile. We move all the "what and when" questions to the PO so we can deliver features on a regular basis.
Let me know if you have more questions.
Education is a vital ingredient in transformations, and it should be one of the first steps you take in moving to agile. Regardless of anyone’s level of agile experience, everyone should go through the same training because the real value of training isn't the lesson plan; it's the shared experience. Everyone across teams having the same foundation is essential.
#NoEstimates is a challenge to the traditional thinking that estimation is essential to agile development. Ryan Ripley believes there are more interesting tools available to help us determine what value is and when we could realize it, while still staying aligned with the businesses and customers we serve. Learn some other ways to deliver value to your customers.