Avoid these common user story mistakes.
In this video, Frank Velazquez explains the problems associated with writing bad users stories. He provides examples of good and bad user stories and explains how writing bad user stories negatively affects Agile value delivery.
You can read the original blog article at: https://agilecheetah.com/the-real-price-of-doing-user-stories-wrong/
Avoid these Product Owner pitfalls to achieve greater product clarity and better team execution.
Table of Contents
The product owner is one of the three roles defined in Scrum: Product Owner (PO), Scrum Master, and the Development Team. The three combine to form the Scrum Team.
The PO synthesizes the needs of product sponsors, stakeholders, customers, and end users (which I refer to as the Stakeholder Community), with input from the Development Team, into a coherent, viable, and executable product vision. The product vision guides Scrum Team decision making.
POs fill the “The Product Management Vacuum” between company/organizational vision and strategy and the work performed by development teams. Effective POs lead conversations about which digital capabilities to develop and why.
Ineffective POs typically exemplify these four characteristics:
The PO is “the voice of the customer” for the Scrum Team. This means POs advocate for the needs, expectations, and desires of customers in the product’s business, mission, or market segment. They define and communicate requirements from the perspective of customers and end users. They can only do so if they posses a deep understanding of the relevant business, mission, or market. In a choice between deep business, mission, or market understanding and technical knowledge, the former trumps the latter.
Ineffective POs lack intimate business, mission or market knowledge. Thus, they often fall into a proxy role between Stakeholder Community members and the Scrum Team. Rather than driving product vision definition in collaboration with the Stakeholder Community and the Scrum Team, they merely document requested features. They struggle to explain the value of requested features or guide Scrum Teams as they learn the business, mission, or market domain.
A product vision communicates the desired end state of a product in business or mission terms. Possessing a deep understanding of market, customer, and end-user needs is crucial but not enough. The PO must leverage that understanding to develop and evolve a product vision. An ineffective PO either does not see the value of developing a product vision or does not have the skills to do so.
Making choices about the product is difficult without a clear product vision. Having one enables the following decisions:
A product cannot be all things to all people. Tough decisions about what to include in a product offering are sometimes necessary. Competing priorities and different levels of power or influence among Stakeholder Community members can make this difficult. An effective PO fosters a collaborative atmosphere of give and take while holding firm to a carefully-crafted and evolving product vision. This responsibility goes well beyond inventorying potential features.
The most glaring characteristic of ineffective POs is that they are often not empowered to make product decisions. This goes back to the earlier point about POs playing a proxy role. In this case, the proxy role is between the actual decision maker(s) and the Scrum Team.
If the PO does not “own” the product vision, someone else does. Often, organizations cede ownership of the product vision to development teams. This is a dangerous situation in any Scrum project because Scrum/Agile projects are primarily scope driven. Without guidance, development teams implement what they think is important and necessary in ways that are most obvious and straightforward to them. This leads to disconnects between what teams implement and the needs of the Stakeholder Community. It also makes it difficult to determine the business or mission value of released capabilities and when capabilities are complete.
The PO brings together people, technology, and processes to develop valuable software capabilities. A product is far more than a collection of related features.
In Scrum, the product is the result of continual verification, validation, and evaluation of increments of capability delivered iteratively. The product evolves cross increments and iterations/sprints based on an evolving product vision informed by input from the Stakeholder Community, development teams, and real-life results/outcomes attained.
Effective POs are empowered to lead product direction, possess enough business/mission knowledge to guide the Stakeholder Community and Development Team, and have the “soft skills” necessary to foster collaborative discussions about needs and negotiations over product features.
Agile Cheetah just added a YouTube channel to our list of platforms. This is another way for us to share knowledge about Agile, DevOps, and organizational agility.
You can subscribe to the channel directly from the watermark link in lower right-hand corner of the video below. Visit the channel and don’t forget to like the video and click on the notification bell to ensure you don’t miss future videos!
Changing Expectations for Developers
Table of Contents
Developers are moving away from functioning as “order takers”, focused almost exclusively on coding, to collaborating with solution sponsors, stakeholders, customers, and end users (i.e., Stakeholder Community) to define, verify, and validate what they develop. Many technical contributors find this level of direct collaboration difficult to manage alongside their growing list of technical responsibilities.
This article is the last of a four-part series about why so many developers are fed up with Agile and why so many organizations fail to achieve Agile’s much-touted benefits. The common thread across the series is that what often passes for Agile is anything but Agile.
The other topics covered in this series are:
One of the defining characteristics of Agile is the fostering of close and ongoing collaboration between software development teams and their Stakeholder Communities. As the fourth Principle of Agile Software Development states:
Business people and developers must work together daily throughout the project
http://agilemanifesto.org/principles.html
Needs, expectations, and feedback from the Stakeholder Community guide what Agile teams build. Delivering features and capabilities iteratively and incrementally affords more opportunities to inspect and adapt deliverables and team processes accordingly.
The ultimate validation of a solution’s value is use by real customers and end users. Prior to release, Agile teams test and validate software increments in collaboration with their respective Stakeholder Communities. After release, development and/or operations teams monitor and evaluate how evolving solutions are used and perform. Lessons learned inform decisions about upcoming development.
Many Agile projects fail because this vital feedback loop breaks down or is never established. Achieving effective collaboration between groups of people who hold different ideas about what is needed or important is difficult. The trust and respect upon which collaboration depends take time and effort to build and are easily undermined. Avoiding or mitigating misunderstandings, disagreements, and conflicts starts with people understanding each other’s perspectives.
Below are some of the most common issues developers encounter when dealing with Stakeholder Community members.
There is also the issue of whether development teams have access to the right stakeholders (or any stakeholders at all). Too often, those who provide requirements do not have intimate understanding of relevant business or mission processes or of customer and end-user needs. This is especially true in organizations with traditional project management cultures where project or program managers, architects, and senior engineers are expected to “know” customer needs yet rarely interact with them.
Collaboration is a two-way street. Agilists approach requirements from a customer-centric perspective. Unfortunately, too many developers think about solutions from the perspective of what they want to build. They define requirements as development tasks to accomplish or as system functionality to develop. In the eyes of the Stakeholder Community, these attitudes come across in the following ways:
Along with increased expectations for Agile development teams to interact with stakeholders, the scope of work done by software developers continues to grow.
Back in the 80s and 90s, a software developer was considered proficient if he or she specialized in one operating system and one programming language. In the 90s and the aughts, many, if not most, developers specialized as front-end or back-end developers. There were much fewer tools to master and most development was custom rather than based on third-party components and frameworks. Also, the work associated with the full lifecycle management of applications was highly specialized and assigned to different people.
The advent of the Cloud and DevOps changed all of that. Now developers are expected to be “full-stack developers” capable of developing both the front and backend components of complete releasable features. Virtual computing and the Cloud broke down operating system-based development siloes. Open-source development wildly increased the number of tools and frameworks available. Great efficiencies brought about by DevOps came at the price of developers learning DevOps tools, developing automation scripts, and managing DevOps pipelines.
A proficient developer today is a master of multiple programing languages, highly conversant in more than one operating system, comfortable using a plethora of tools and frameworks, and regularly contributes to testing and DevOps automation. Software developers now perform a lot of work that used to be set aside for specialists such as system administrators, configuration managers, build engineers, testers, etc. While a lot of that work is now automated or abstracted away from developers, the scope of what is considered development work is much larger than before.
Many software developers feel overwhelmed by expectations to keep up with the ever-increasing pace of technological change, consistently deliver value, and collaborate with stakeholders. Most developers entered the field for the opportunity to develop software for a living and concentrate on becoming better technologists. They become highly proficient at building software but lack the business or mission insight necessary to better align solutions with business or mission needs.
Development teams do not need to choose among better collaboration with stakeholders, maintaining technical excellence, and delivering value cost effectively and in time to be valuable. To achieve that balance, we recommend the following actions.
While not all Agile teams are Scrum teams, Scrum’s concept of Product Ownership is useful for managing Stakeholder Communities and can be tailored to work with non-Scrum Agile teams. In Scrum, the “product” is synonymous with whatever technical capability a Scrum Team develops, be it a system, solution, application, etc.
A Scrum Product Owner (PO) is responsible for fusing the various needs, wants, and perspectives of product and project stakeholders into one complete, coherent, and cohesive vision. The Scrum Development Team looks to the PO as the primary (but not the only) source of business or mission knowledge and understanding. The PO enlists the help of the development team and the Stakeholder Community in defining the product/solution but is primarily responsible for outcomes.
An empowered PO is able to do most of the heavy lifting associated with managing a solution’s Stakeholder Community. While software developers are free to work individually with any stakeholder, the PO ultimately decides what features make it into the product and the nature of those features. This arrangement provides developers a dedicated Scrum Team liaison to the Stakeholder Community who is well-informed and respected by the community.
Customer engagement and requirements elicitation are learned skills. While some people have more of a knack for them, everyone can benefit from training and mentoring in those skills. Such training would include topics such as:
Investment in these “soft skills” pays off in better communications between development teams and stakeholders, better requirements definition, less rework, and greater customer and user acceptance of delivered solutions.
Development teams have more time to interact with stakeholders if the amount of work they commit to is in line with their capacity to complete it. As explained in the first article of this series, software development teams that do not have control over the amount of work they commit to are not Agile teams.
Another way to open up time for developers to collaborate with stakeholders is by providing access to technical training and setting aside time to take advantage of it “on the clock”. Done well, this investment can bring about better prepared and more knowledgeable technical contributors, better solution implementations, cost savings due to decreased rework, and a boost in employee morale and goodwill towards employers.
Often, development teams do not possess specific hard-to-find skillsets or may not have the bandwidth to learn them. One way to meet short-term development needs while passing along knowledge is by partnering developers with technical consultants. This learning by doing model accelerates learning, thus providing development teams more time to interact with stakeholders.
Developers and stakeholders benefit greatly from closer collaboration in defining solutions. The keys to improving that collaboration are:
This series covered a lot of ground concerning the frustrations with Agile software development shared by many developers. I too have participated in “Agile” implementations that failed to be Agile. What those failed implementations had in common was an inability or unwillingness to let go of traditional project management biases rooted in Taylorism. The challenge is not in training people on the mechanics of individual Agile approaches. It is in chipping away the Industrial Age organizational mentality that stifles progress in today’s cyber-driven world.
The Agile Manifesto is a clarion call to improve how we work by acknowledging the skills, knowledge, talents, and professionalism of today’s knowledge workers. Agile is an ever-evolving domain filled with practitioners dedicated to improving it. It is that ethos that keeps me optimistic about leveraging Agile to improve not just software development, but world of work in general.
