Why Stories Work where Requirements Documents Fail

In a traditional development practice, a product manager writes a long document describing the software requirements. Hopefully the document is diagram heavy, clear and concise. The document is handed to analysts who break the requirements down to development tasks and a project manager develops a schedule and assigns resources to tasks.

In my experience, this rarely happens. In the real world, requirement documents are rarely complete and the software developers themselves are developing the architecture directly from the requirements document. Things look good for the first few weeks of the development cycle until the requirements change and the product manager updates the requirements document. Hopefully the product manager turned on 'track changes' so that the developers can see the differences. But even in this scenario, multiple changes over the course of a larger project are difficult to document and track properly. The result can be inconsistent requirements. In addition, the developer is probably getting tired sifting through the changes in this document and asks to have meetings to ask questions. The developer listens, writes a few notes and goes off developing. Maybe a detail is missed here and there or something is lost in the translation. Skip ahead a few weeks and the product manager is recording defects.

If only we could simplify. Maybe have the product manager and developer talking right from the beginning thinking through the designs and requirements together. After all, developers need to understand the business and lets face it, the technology isn't all too complicated today for product managers to talk tech with a developer. Maybe the requirements of a feature can be drafted together as a... a... short story. Yes, a story. Something everyone can read and understand. But lets make sure that some of the specific requirements are also written down in a clear concise way so there's no ambiguity on the deliverable. We should probably call these acceptance tests. Now that the developer understands the feature well, maybe she can even provide a time estimate. Hmm, the product manager says, that estimate is kind of high, can we simplify and do it cheaper? Sure she says, but only if we simplify these requirements. The product manager thinks about it and agrees. The developer then commits to this contract and does her best to complete it as specified. That's not too difficult because she understands the story and has all the details on the one page contract sitting in front of her as she develops the code. When the contract is done, she reviews the feature with the product manager along with all the acceptance tests.

The product manager and developer repeat this approach again and again. After the fifth iteration, the product manager thinks to himself, "Wow, this way of working together is really agile."
continue reading "Why Stories Work where Requirements Documents Fail"

Why Agile Product Planning Is Important

Most agile product planning revolves around the commitment of stories to an iteration. This specifically addresses how many stories, story points, or features can be completed in an iteration. Stories are estimated in points and a team's velocity is measured as the total number of successfully completed story points in an iteration. If the velocity is consistent, the team can estimate the stories that can be committed in future iterations.

This process can work well for single (or few) iteration estimations. But what happens when stakeholders require some longer-term, multiple iteration estimations. Given a long list of priority features, how many of them will be completed 10 iterations out?

When I talked to agile practitioners and scrum masters, some of them were against this level of estimation. After all, the point of agile is to be able to prioritize features based on changing needs, so why bother even trying to estimate feature delivery over multiple iterations?

Point taken, but this line of thinking misses the point. Long term estimation doesn't imply a rigid, non-agile plan. The plans may change, but given your best estimation today, the stakeholder should have the right to know whether the complete product deliverable as visioned today can be delivered in a reasonable amount of time and cost.

This is really critical when development teams in a large enterprise want to adopt an agile development process. Enterprises invest in product development based on financial merits and other drivers and want time estimates for a feature and product development. In addition, aligning the product deliverables with other needs such as marketing and sales requires estimates on deliverables and timelines.

So even though a team may be following an agile development process and allow stakeholders to adjust priorities, it's still important for the managers of these teams to adopt methodologies for estimating product deliverables and timelines.

Updated: Learn more about agile continuous planning.
continue reading "Why Agile Product Planning Is Important"

Agile in the Enterprise: Big Questions Enterprises Should Consider When Going Agile

When a CIO, development manager, or a team decides to 'go agile', what does this mean for other colleagues that work with this team? What does it mean to Product Managers that are responsible for developing business cases and delivering product requirements? What happens if there are technical teams that are on the periphery of the core software development group such as QA teams, operations, offshore teams, or shared services? What about enterprise architecture teams that set standards; how do you handle conflicts with the technology and process choices selected by your self organizing agile team? How does an agile delivery affect the strategic and product planning process?

Small teams and startups in particular don't have to address these questions. But larger organizations looking to move to agile delivery models have to consider some of these questions. I recall one ScrumMaster that initially frowned at me when I suggested we could follow agile methods for planning iterations, but eventually we would need to put a forecast on feature delivery for several months (and many iterations) into the future. "That's not agile" was a response I got initially and it required some dialog to convince him that agile in the enterprise required this type of planning.

These questions don't need to be answered all at once. In a true agile approach, leadership can look at these and other questions and prioritize based on needs. But larger organizations should consider developing a team and process that focuses on these questions.
continue reading "Agile in the Enterprise: Big Questions Enterprises Should Consider When Going Agile"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.