A stakeholder is anyone who can affect, or be affected, by the actions of a business, in part or as a whole. Examples: team manager, product manager, president.
Complexity is the sum of all of the work that is required to get the feature from concept to market (live, released). Fundamental building blocks of complexity include, but are not limited to, time and effort needed to complete a task.
A unit of work is any block of code that could be deployed without breaking the system. It may be a work in progress. It doesn't need to provide full business value, however it should incrementally drive code base toward providing expected business value.
The developer delivers business value requested by a stakeholder.
The first "end", in the end-to-end process, represents the story kick-off meeting. The second "end" represents the terminus where the feature meets the requirements for the team's "definition of done." The definition might include a demo or communique to the stakeholders that the story, and its feature, is live.
Throughout the development process the developer, must remain in a constant feedback loop with the stakeholder, directly or through a proxy. Communicating at least once a day, if not many times a day is essential, event if only to say: "this is where we are today." Some variation of a stand-up meeting is the perfect opportunity to give an update on progress and any obstacles to further progress.
The only other communication a developer should have is with the developer's manager.
All non-stake-holder communication to a developer must come through the manager.
**Outside pressures and the developer's tendency to people please are poison to productivity and the development team. **
Your job, as a developer, is to provide business value to your company, either directly or indirectly through units of work.
What is business value?
Business value is whatever the stakeholder says it is.
This authority to decide what is and isn't value goes up the hierarchy chain, unless otherwise noted.
What I, the developer, think about the business value of a feature/priority is superceded by...
What the product stakeholder thinks about the business value of a feature/priority is superceded by...
What the manager thinks about the business value of a feature/priority is superceeded by...
What the company owner thinks about the business value of a feature/priority...
Story points are a unit of measure for the complexity required to complete a story. They are not a unit of time required to complete a story. Contradicting the statement just made, my experience has been that, sooner or later, almost all "agile" teams converge on using point values, and scale, derived from time estimations. This derivation is the easiest way for devs to estimate, and for managers to understand. Do not be discouraged if this happens, just see what happens.
There is much debate in the world about what a point value is and there is equal confusion on how to use point values in practice. In addition, there is the issue of point scale.
Do you use incremental point values -- 1, 2, 3 -- fibonacci -- 1, 2, 3, 5, 8 -- or t-shirt sizes (s,m, xxxl)? What rules govern how to treat each value? Is a point value of 3, three times greater the complexity of a 1 point feature? Or is it three orders of magnitude greater?
What about evolving workloads and scaling? Point inflation and deflation? If the smallest point value is one (1), is that a story like adding a button to an html page? Well what about stories that are smaller than that? Do we group many micro-stories together so that they approach the complexity of that 1 point button story.
In time, the context in which the original one-point story was created will be lost. A team's usage and scale of point values will evolve, accordingly.
Again, communicate or fail. What is important is communication between the dev team and stakeholders. Point inflation can occur rapidly, if the team feels pressure. Beware that if the team is only measuring velocity as the metric of the teams performance, other metrics such as code quality, maintainability, and best practices may, and usually do, suffer. Points are a tool, they are not part of the Agile manifesto. They are not necessary, and they are certainly not a silver bullet for poorly performing teams.
points = business_value * (known complexity * normalized)
if there are "known unknowns"
bump point value to the next little of complexity
end
if there are "unknown unknowns"
bump point value two levels of complexity
end
A feature is any unit of work, or group thereof, that meets this criteria:
- has business value
- is requested by a stakeholder
- provides demonstable functionality to the product
- it takes input, returns output
Business value is defined above.
The stakeholder needn't be outside the dev team; however, a stakeholder/developer must decide what hat he/she is wearing. If the request is made wearing the "developer hat," the request might be a chore masquerading as a feature.
Demonstrable functionality needn't be a "form button," it can be improved search results, response times, a 3rd-party ack, etc.
http://scaledagileframework.com/spikes/
A spike story is special type of story used for investigative and exploratory purposes. The objective is to flush out and flesh out everything that can possibly be known, as well as shed light on the unknown, about a story before a single finger hits the keyboard.
A spike story has a value of zero points and its definition of done is one or more features, chores, bugs, and possibly other spike stories.
Note: the link above says that spikes should be estimated. I discuss why I believe they should have zero point value, below.
A chore is a task, or group of tasks, that match these attributes:
- Not attached to a feature story
- Doesn't include a codebase modification component (code!)
- Is not requested by a stakeholder
- Is needed to remove obstacles blocking future development
E.g.: 1-off deployment tasks, new server provisioning, documentation, sending a newsletter, user education
A bug occurs when the expected behavior of a piece of code doesn't match its output. This dissonance may be attributed to conditions, context, or environment.
Note: A feature that fails to meet the functional specifications, requirements or expectations of a stakeholder is not a bug. This is a failure of process.
Technicaly debt needs to be payed off sooner, rather than later. App rewrites are almost always due to technical debt that has become unmanageable to the point of developer paralysis.
If bugs are found in the current sprint, they must be handled based on two states. If the code has not been shipped, stop the line. Don't ship this code. If the code has been shipped, the bug should be placed at the top of the next sprint, and given an emergency deploy to patch the bug once a fix is in.
If bugs are older then the current sprint, they should be prioritized with dedicated time in the sprint. Sooner or later the bug becomes the feature. Let's try to avoid this: http://www.bbc.com/news/technology-30019976
When a feature is shipped that fails to meet a stakeholder's expectations, this exposes a huge problem in communication. I call this a "process bug." If deadlines, monies, or other dire consequences are in question, these process bugs can hurt or destroy departments and companies.
My experience has been that a tighter feedback loop can remedy most of these developmnent problems.
If the developer repeatedly fails to meet expectations of a stakeholder, move him or her to a pair.
If the pair of developers repeatedly fail to meet expectations of a stakeholder, move the pair next to the product stakeholder, and demand feedback on every code commit. Does this look right? Test it. Does this look right? Test it. Does this look right? Test it.
Any repeated failure to meet stakeholders expectations should be scrutinized by the management. A "stop the line" approach needs to be taken if the process is to get back on track.
Spikes, other zero point features, chores and bugs are extremely important to keeping the team honest about their velocity, as well as giving stakeholders a realistic expectation of a teams productivity and release schedule.
My experience has been that developers believe that points are the currency or receipt or work. Dpikes and bugs and chores are work, take lots of effort and in some cases days or weeks to figure out to resolve. Given that I suggest giving these zero points may result in some developers feeling that they aren't getting a fair credit for the efforts they have put in on the code base. Who among us hasn't wanted to knock about a dozen green field stories, rather than take on the bug that seems to never go away?
First: teams should be judged on points. There is very little reason to discuss point values on an individual basis. For obvious reasons.
Second: Zero-point work should be spread around the team so that everyone gets a taste.
Third: It keeps the velocity as a measure of shipped business value honest.
If you have a full week of spikes, how much business value did you actually contribute to the company? The bottom line? Lets extrapolate this, a year of spikes. Yeah, spikes take effort, time, possibly prototyping, and brain power. If spikes provide zero business value, if code is not shipped, then I find it rather silly to give spikes points that might lead a manager to think that value was delivered to the business. Vaporware is seldom appreciated in competitive times.
Now, lets take a look an example work week. Lets say that a team has a velocity of 20 points a week. This week, however, they receive some green field work that requires research. Twenty percent (20%) of the work time is used to spike, so this weeks expected goal is 16 points. After the week the manager asks why the velocity dipped. "The spikes worth zero points" needs to be an acceptable answer. If the spikes were given 4 points, it would be disengenuous to state that the steam added 20 points of business value, having honestly delivered roughly 80% of the previous weeks value. Giving points to spikes is point inflation, and can quickly get out of hand.
Bugs are no different. A week spent on bugs should total a velocity of zero points. Bug fixes, code patches, satisfy previous "contractual obligations" to business stakeholders. You don't get extra credit for introducing, and then fixing, your own bug.
A bug may be current tech debt (like current liabilities) or long term tech debt depending on how long it has been in the system. Current liabilities, bugs known or found since the last sprint should be fixed immediately. Other bugs should be prioritized, accordingly.
Chores do not add business value. They are a necessary component of running a business. No one is arguing that adding documentation, teaching users how to use the features, cloud management, server provisioning, etc isn't work. A chore doesn't business value to the application.
The process is a series of conversations between the stakeholder and the developer. Through a rapid iteration and feedback loop, these conversations get fleshed out into actionable stories and tasks. These stories and tasks get executed by the developer, accepted by the stakeholder and staged into a branch of code. This branch of code is merged into the master code base and deployed at the earliest convenience to the. The code is, then, maintained
..forever
..seriously
..forever.
The stakeholder meets with the developer and explains the project, and subprojects, going from general to specific to provide as much context as is known at the time of the meeting. The stakeholder must avoid implementation details, but must have an idea of how the end-user needs to be able to view, or use, the results.
The developer considers all known system & domain logic, how the new functionality may fit into the existing system. At some point, the developer might suggest solutions, or alternate behavior, that has worked for similar problems.
Remember that neither the developer, nor the stakeholder, has identical knowledge of each other's domain, experience, or context. This is one reason why a stakeholder should avoid giving implementation details to the developer, and why the developer should avoid opining as to what s/he thinks the end-user really needs.
At the end of the day, the stakeholder calls the shots. "You're the boss, applesauce." Any serious disagreements may be discussed with your manager, and passed up the chain.
Example of a quick kick-off
Stakeholder: We want to start a Brad's Deals Gift Guide section. Every gift guide can have many collections. A collection can have many deals. There is an admin component, which should look like the other admin views and forms. There is a public facing side component, and we will get you mocks asap.
Developer: Jeah!
The developer should leave the kick-off meeting, fresh knowledge in mind, and write up the story cards. The stories are conversation starters, or continuers -- that is it. Implementation details be damned!
Example of a story w/ questions:
A Guide Guide Can Have Many Collections
-
What fields are stored in a guide?
-
What fields are store in collection?
-
Can a collection have many guides?
These example questions should be on the story card and responded to, immediately, by the stakeholder. The stakeholder should also discuss any litmus tests for acceptance, or the definition of done, and those should be placed in the story details or comment section.
As these questions are answered, more will be raised, executed, discarded, or exhausted. The conversation moves from general to specific, and then to action. Speed up the feedback loop by daring to walk over to the stakeholder and asking the questions verbally. Note the verbal answers in the story card.
As the stories get fleshed out, the action items are pulled into focus. Those fingers are getting a lil restless. It's time to code. Start coding the solution, in a general way, reducing it, refining to elegance.
_Every block of stone has a statue inside it and it is the task of the sculptor to discover it.
- Michaelango_
Keep in mind:
-
red, green, refactor!
-
leave the codebase cleaner than you found it
-
don't over engineer
-
"take the first bullet" then pull out the abstraction
-
adhere to S.O.L.I.D. principles, always, and forever
-
comment why?, not what.
-
reduce what and how comments by rewriting code
Until the stakeholder and developer get into such a groove that their feedback loop borders on mindreading, the stakeholder should review every story's progress, even if its not in acceptance state, where possible. If the stakeholder is unable to verify the story it should be done by a peer of the stakeholder.
Face-to-face communication is expected in addition to the use of information radiator such as a Kanban/Scrum board, wall of post-its, etc.
The short answer is: who knows?
If the agile manifesto, and lean SDLC was the end all, we wouldn't have Agile vs agile, and Scrum vs. Scrum-but. The fact is this, the Agile Manifesto and the Scrum, Lean, Kanban communities have given us a new paradigm to work with. The teams must self-organize and accept how they choose to work with it.
In the end, the development team must decide what works for them and the company. Don't sacrifice culture and productivity for Agile worship. On the flip-flop, if you need to get rid of some toxic, albeit brilliant, developers to bring process and order to the chaos, reach for clorox!
In the Business Value section, under What Is Business Value, when the product owners vision of value can be superseded by the mangers vision, does manager refer to the product owner's, stakeholder's (assuming product is working as a proxy for a stakeholder), or developer's manager?