Advancing Business Value With ATDD User Stories
Breaking down user stories into incremental sprints iteratively clarifies the business value of project development and enables smoother testing of the application.
Join the DZone community and get the full member experience.Join For Free
as businesses compete globally, enterprise goals seek to allay obstacles to projects and organizational success. in a fluctuating economy among fluctuating consumer preferences, companies must sell services with applications and innovation with reliability. awareness and development toward relieving challenges to deployment that reduces the cost to the market and increases roi becomes vital. agile product development user stories initiate the solution to the issue of profitability in an ever-changing and uncertain business environment.
developing user stories is primary to delivering quality software. user stories form and formulate the foundational information that allows developers to initially estimate the effort and timespan in development. stories start out with lean and high-level requirements to clarify the project goal with the customer who will become the stakeholding user of the product. the definitive format for a user story is:
as a [type of user]
i want [to perform a certain task]
so that i can [achieve a goal, benefit, or value]
“as vice president of r&d
i want to update cad
so i can view specifications in three dimensions.”
the user story, when broken down in this manner simply, succinctly, and decidedly, generates an undeniable understanding of the work to be done and how the work supports and advances enterprise goals. r&d feeds into new customer-engaging products, which feeds directly into the business roi. cad updates feed into r&d as facilitators of progress and process. a 3d view of specifications feeds directly into cad updates as the manner in which the updates occur. therefore, each incremental component or task of development sequentially feeds into and supports the enterprise.
the user story contains the subject or focal point of development, the user, the desired manner of performing the work, and the focal point of desired results. therefore, the project stakeholder, rather than the developers, essentially writes the user stories , many times on index cards and post-its (the simplest tools available).
estimating with the fibonacci sequence
developers break high-level user stories into tasks from which they can estimate in the form of story points the effort, and therefore anticipated relative timespan, for development. story points use a fibonacci-type formula of number sequences to estimate relative time spans. story point number sequences are 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, and so on, in which every number in the sequence is the sum of the two preceding numbers. the abstract aggregation of comparative magnitude in size and effort is illustrated below.
the figure is a size comparison that also specifies a number for each size. viewing this, for instance, as a set of rooms that need flooring, the floor layer estimates that it will take 21 hours to place flooring in the largest room. the next size room is a little more than one-fourth the size of the largest room. with the same detail in a lesser area, the floor layer estimates a timeframe of 13 hours to place flooring (the next lower number in the fibonacci sequence). a smaller room is estimated at eight hours, and so on.
translated into software development tasks, a larger task of setting up a 3d design may be estimated as a 21-hour workload. in comparison to the size of the 21-hour workload, a lesser task of sequencing specifications into 3d design may be estimated as a 13-hour workload. in continued comparative estimation, color coding the design format may be viewed as an 8-hour workload. when estimating all task breakdowns of the user story, developers are able to submit an initial timeline to the user/stakeholder. in the same manner, the fibonacci strategy can also be used in estimating task priority.
comparative estimation using the fibonacci sequence allows project development to present a time estimate to stakeholders, or project owners, which allows the enterprise to quickly gain an initial picture of project costs and time to market. rather than simply hoping to balance the project budget, management observes (from project start) the degree and amount of investment the project requires, as well as projected profit margins.
the project manager, stakeholder sponsor, or team coach bear the responsibility of meeting enterprise requirements in project development. agile teams usually produce in one- to two-week iterations, or sprints, allowing stakeholders to incrementally view progress and gain insight into procedures. once a sprint is planned within the team, commitment to the plan remains throughout iterative development. dedication to a sprint towards a shippable increment enables teams to view and determine what works or doesn’t, and why or why not. deficiency issues that may have been missed in mid-evolution of a software component, can be viewed in entire format by both developers and stakeholders within the completed sprint.
large projects have a number of user stories. the composite of stories determines the scope of a project. new stories can be identified, split, or removed during iterations. however, in respect to organizational investment, the full development function is pledged to stay close to the estimated timeline. as stories and tasks evolve over time and are incrementally shared with stakeholders, they can become completely revised to achieve stakeholder goals or changing enterprise resolve.
the high-level makeup of user stories requires the input of detail through conversations between stakeholders and project teams. often the use of atdd, or acceptance test-driven development , allows developers to determine whether project iterations are meeting user needs. as well, methods that include screen sketches in which users actually become involved in the ui mock-up and acceptance validation criteria, assist in developers ascertaining the best development methods to satisfy project owners. atdd functional tests verify the goal and purpose of the software increment.
acceptance test driven development
atdd testing allows stakeholders as users to verify the operational integrity of software development in incremental units, rather than after full completion. incremental deficiencies can much more easily be remedied than full levels of production. innovation can be advanced without exaggerated risk. investment can be allocated to a more stabilized development. cost to market and roi can be anticipated in more finite terms.
xp and atdd
in extreme programming, or xp, the stakeholder or product owner defines the priority order of features the project team is to develop. while the stakeholder determines priorities, the development team chooses the task sequence. task sequences seldom deviate from the selected priorities unless priority items do not fit well with the sprint. in the case of conflicting priorities between project owners and the project team, interactive communication smooths the programming process.
atdd, tdd, test-driven development, pair programming, focused automated testing , refactoring, and simple design are central engineering practices within xp. in-depth analysis of priorities detects whether the sequence is valid within incremental planning, design, and development, as well as project goals. to determine the validity of xp priorities, stakeholders, enterprise management, and project teams collaborate on project goals and business advancement. xp is often driven by enterprise precepts to allay management concerns regarding risk.
the successful breakdown of user stories into tasks, or sprints, leads to:
- the enterprise goal having been met.
- the “definition of done,” which leads to customer engagement.
- reliable and repeatable team processes.
- promotion of enterprise roi.
- enhancement of enterprise standing in the market.
- few improvement issues within the retrospective.
a compromised breakdown of user stories into tasks, or sprints, reflects:
- possible conflict or poor communication between the project owner and the team.
- failing to attain “definition of done.”
- a retrospective with a high number of improvement issues.
- having a negative impact on enterprise advancement.
however, even compromised sprints can bring certain advantage to organizations:
- an uncommunicative product owner may be replaced.
- cost savings may be realized with the early project termination of a project rather than failing to deploy after a long-term effort.
- the team and organization draw out valuable information on what not to do.
in a world economy that is undergoing unpredictably rapid change, business is finding it extremely difficult to anticipate consumer needs. the uncertainty within the fluctuating economic environment is both a distractor and an advantage. an enterprise that can quickly leverage ever-changing circumstances with continuously impactive application can gain significant market share.
management must apply vision to enterprise goals to advance profitability in an uncertain market. within sprints project stakeholders must track requirements throughout the development process unto completion. as the project evolves, stakeholders and management are responsible for analyzing the impact application development and deployment will have on enterprise goals and consumer engagement. in light of the challenging business climate, project owners must:
- create the team goal.
- consistently review that development ties into the goal.
- trace the changes brought about through new development.
- analyze the impact of change.
- stay abreast of continuous changes within the market.
- assure that development consistently expresses business values.
- invest in the right tools such as enterprise test management .
agile culture focuses on continuous feedback to management. the breakdown of user stories adds detailed definition to the culture. with a high rate of user satisfaction and acceptance, agile is in a prime position to revolutionize software deployment. the incremental breakdown of user stories activates revolutionary process and purpose of agile methodology. the quick and incremental release of quality software products not only boosts business revenue and positions enterprise in favorable positions within the market but also requires that management consistently maintains an overview of progress in development.
breaking down user stories into incremental sprints iteratively clarifies the business value of project development and enables smoother testing of the application. business analysts are able to delineate required enterprise expectations, while software developers can create optimal manners in which to implementing business requirements. applying the breakdown of user stories to both agile and business development clearly brings agility to business.
Published at DZone with permission of Sanjay Zalavadia, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.