Tag Archives: User Stories
Allowing for Cross-Functional Teams
A home entertainment provider called me in to facilitate User Story writing followed by release planning. The business unit had not tried either activity before. Leadership had been replaced and the new General Manager and Vice President of Technology decided to invest in the group’s burgeoning Scrum effort. The organization followed a structured work breakdown approach with tasks functionally derived. People were willing to approach product definition in an Agile way and wanted to experiment with User Stories. We discussed the vertical nature of Stories and that teams were formed orthogonally, based on the architectural stack. A few people pointed … Continue reading
Finding Predictability in the Velocity
Being an independent contractor is exciting yet somewhat lonely, having to support myself and find every opportunity. I look to constantly improve my craft by finding others to collaborate with and have found those needs met by joining Rally. I now concentrate on improving my coaching and training practice with other coaches. We have a support system around us and I get to work with people who have different strengths and skills. One of the clients I work with is a networking company. One of the teams I worked with had a difficult time establishing a consistent velocity. Forecasting when … Continue reading
Gauging the Rate of Progress
An interesting pattern was revealed to me. I noticed it in my embedded team and with other teams who asked for help. Product Backlogs were not being estimated. Teams were not estimating in points, days, nor even time. It is unclear what led to this lack of discipline. A consequence of teams not being able to say when something might be done resulted in other people setting deadlines for those teams. Playing the Team Estimation Game Demand for coaching was high and we were always being called in to situations. In looking around if I found a backlog with hundreds … Continue reading
Reassigning Points to Validate Estimation
Keeping a Good Agile Estimation Practice As part of our Scrum practice at vianet, we spent time as a team tending to the Product Backlog. We played planning poker and kept all our stories sized. We knew the entire size of the Product Backlog. Every Sprint we looked ahead and refined some User Stories. Our velocity was stable and we could predict what User Stories would fit in a Sprint. The total size of the Product Backlog and the number of Sprints left projected that we would not hit the date promised to the customer. Verifying the Estimates The Product … Continue reading
What do you think the INVEST acronym is for #Agile User Stories?
This is a question I asked recently of a newly-formed Scrum team in a User Story Writing workshop. It occurred to me to not just blurt it out and to let them offer suggestions instead. They were very willing to contribute and I’d like to share the answers they came up with: I Improve, Innovate, Integrate, Intent, Invent, Interesting, Initial N Navigate, New, Novel, Negotiate V Viewable, Viable, Value E Effective, Easy, Evaluate S Stable, Scope, Simple, Satisfied, Success, Scalable T Testing, Time After a couple of rounds of shout-outs I asked if they’d like the answer, and they kept … Continue reading
What a Pile of Product Backlog
What is all this stuff? Can we take a look at the Product Backlog? Does this backlog contain a long list of prioritized “stuff to do”? Does this list include defects, functional tasks and/or feature requests? What else? Does this list include everything? Are there more items in the backlog than we can see in one glance? Have we determined the business value in this “stuff” as a basis for stack-ranking these Product Backlog items? Can we estimate this “stuff” in terms of relative complexity and help with prioritization? In reality do we have multiple lists for the product being … Continue reading
Death by Scrum Meeting
I recently received an email from a senior-level manager, who raises a valid question about all the meetings associated with Scrum. This particular instance of Scrum has over 50 people working in more than one locale. When yet another meeting was created, he raised a valid question: 90 minutes every week for backlog hygiene? And that is on top of all other scrums, scrum of scrums, business reviews, can we ship, planning etc. meetings and scrums? I am getting seriously concerned about our state and efficiency. If we need to spend 90 minutes on this weekly, than, IMHO, someone is … Continue reading
Leading a Retrospective Before Introducing Kanban to a Team
Introduction On September 25th I facilitated a Product-level retrospective. The purpose of this retrospective was to look back at how user stories find their way to production, and to find ways to shorten the process and increase quality. The format of the retrospective was taken directly from the book Agile Retrospectives. This style can be used on iteration/release/product cycles. It breaks the meeting down in to 5 components: Set the Stage, Gather Data, Generate Insights, Decide What To Do, and Closing. There are many activities which can be used to help with each phase. Choosing the correct activities becomes much … Continue reading
Naked Planning Explained – Kanban in the Small
While attending Agile2007 I kept finding myself in the company of Arlo Belshee, especially as he was going through his implementation of a Kanban System at BlueTech LLC. The conversations became for me one of the stand out ideas discussed at the conference. This process might have started when Arlo really got in to the lean literature and looked around for waste in the Scrum system. He believed he found it in estimation. The amount estimated to work always differs from actual amount worked, is therefore supposition and only a guess, so this estimation was declared muda. There are a … Continue reading